[Chapter 23] 23.3 Access Configuration--access.conf

23.3 Access Configuration--access.conf

The NCSA and Apache servers provide a system of security to sensitive documents on your server by allowing you to restrict access to directories. Access can be determined based on username/password authentication, IP address, or a combination of both. Directory access is controlled by the use of access configuration files (ACFs).

You may control access to any directory in your document tree with a global access configuration file. The global ACF lives in the conf directory and is specified by the AccessConfig directive in your httpd.conf file. The default is access.conf. Global ACFs have the userid and groupid of the server daemon, and therefore, the server administrator should be the only person who has access to the file. A global ACF is required.

You can also have per-directory access configuration files. These files describe access control for only the directories that they live in. Per-directory ACFs allow users who have write permission to certain directories available on the server to establish their own access rules. The name of per-directory ACFs is specified with the AccessFileName directive in the srm.conf file. The default name is .htaccess. Per-directory ACFs can be restricted or forbidden in the global ACF.

Both types of ACFs are constructed the same way, except for a few additional directives in global ACFs that specify directories and overrides.

Basically, an ACF does one or more of the following functions:

Specifies the name of the password file where valid usernames and passwords are stored.
Specifies the name of the group file where valid groups of users are listed.
Sets the limits on who can access files in the directory and with what methods.
Specifies which advanced features are allowed to be performed within a directory.

This is an example of a global ACF:

<Directory /projects>
 Options All
 AuthType Basic
 AuthUserFile /usr/local/etc/httpd/conf/.htpasswd
 AuthGroupFile /usr/local/etc/httpd/conf/.htgroup
 <Limit GET>
   order allow,deny
   allow from all
 </Limit>
</Directory>
<Directory /projects/golf>
 <Limit GET>
  order deny,allow
  deny from all
  allow from .golf.org
 </Limit>
</Directory>
<Directory /projects/golf/team>
 AuthName For Team Players Only
 <Limit GET>
  require group golfteam
 </Limit>
</Directory>
<Directory /projects/golf/team/captain>
 AuthName Captain Only
 <Limit GET>
  require user captain
 </Limit>
</Directory>

This example shows the various ways in which access control can be implemented. The global ACF uses the Directory sectioning directives to enclose access information for different directories (wildcards may also be used to designate a set of directories). The settings for each different directory apply to that directory and all of its subdirectories unless overridden in a lower directory's specifications.

Per-directory ACFs contain the same information as <Directory> ... </Directory> sections, except without the Directory tags. Use of per-directory ACFs is controlled by the AllowOverride directive within <Directory> sections in the global ACF.

Password and Group Files

For user and group level authentication, a password file is needed. The location and name of the password file is specified in the AuthUserName directive. The easiest and most common way to create a password file is to use the htpasswd program that is distributed with the server. To create a new password file to store a new username and password, use this command:

% htpasswd -c pathname username

The -c option tells the program to open a file with the given pathname. The program will ask you to type the password you want to use for the given username twice, and the username and encrypted password will be stored in the new file. Other users can be added to the file by using the same command and pathname without the -c option.

Password files created with .htpasswd are similar to UNIX password files. Keep in mind, however, that there is no correspondence between valid users and passwords on a UNIX server and users and passwords on the Web server. You do not need an account on the UNIX server to have access to the Web server.

You can corral several users into a single named group by creating a group file. The location and name of the group file is specified with the AuthGroupFile directive. Each line of a group file specifies the group name, followed by a colon, followed by a list of valid usernames that belong to the group:

groupname: username1 username2 username3 ...

Each user in a group needs to be entered into the password file. When a group authentication is required, the server will accept any valid username/password from the group to allow access.

The .htpasswd user authentication scheme is known as the basic authentication method for HTTP servers. Apache and NCSA allow other types of authentication methods, which are configured with a similar set of directives.

Access Configuration File Directives

This is a listing of all of the directives that may be used in global and per-directory access configuration files (ACFs).

allow

allow from hostnames ...

The allow directive is used within the <Limit> section of an ACF. It specifies which hosts can access a given directory with a given method. The hostname can be any of the following:

domain name

A domain name, like .ora.com. Only hosts from that domain are permitted access.

host name

A full hostname.

full IP address

An IP address of a host.

partial IP address

The first 1 to 3 bytes of an IP address, for subnet restriction.

`all`

Using the word all means that all hosts are allowed.

There can be only one allow directive per <Limit> section. If omitted, there is no default.

AllowOverride

AllowOverride options ...

Controls the extent to which you allow local per-directory access control files to override the global access defaults defined by the access.conf configuration file. The directive takes one or more options, which can be:

`None`

ACFs are not allowed in this directory.

`All`

ACFs are unrestricted in this directory.

`Options`

Allow use of the Options directive.

`Indexes`

Allow use of directory indexing directives.

`FileInfo`

Allow use of the AddType and AddEncoding directives.

`AuthConfig`

Allow use of these directives: AuthName, AuthType, AuthUserFile, AuthGroupFile, or any other Auth* directives.

`Limit`

Allow use of the Limit section directive.

The AllowOverride directive can only be used for the global ACF. If omitted, the default is:

AllowOverride All

AuthDBMGroupFile

AuthDBMGroupFile filename

The Apache server can be configured to use DBM authentication in addition to basic authentication. The AuthDBMGroupFile directive specifies the location of the DBM group file. It replaces AuthGroupFile when DBM is used.

AuthDBMUserFile

AuthDBMUserFile filename

The Apache server can be configured to use DBM authentication in addition to basic authentication. The AuthDBMUserFile directive specifies the location of the DBM password file. It replaces AuthUserFile when DBM is used.

DELETE

AuthDBUserFile

AuthDBUserFile filename

The Apache server can be configured to use Berkeley DB authentication, for sites that support DB but not DBM. The AuthDBUserFile directive specifies the location of the DB password file.

AuthDBGroupFile

AuthDBGroupFile filename

The Apache server can be configured to use Berkeley DB authentication, for sites that support DB but not DBM. The AuthDBGroupFile directive specifies the location of the DB group file.

AuthGroupFile

AuthGroupFile filename

Specifies the group filename as an absolute path. For example:

AuthGroupFile /WWW/Admin/.htgroup

AuthName

AuthName name

Sets the name of the authorization realm for this directory. The value is a short name describing this authorization realm; it can contain spaces.

AuthType

AuthType type

Sets the type of authorization used in this directory. Basic authorization is the most commonly used method.

AuthUserFile

AuthUserFile filename

Specifies the file that contains a list of users and passwords for user authentication. The file name is given as the absolute path of a user file created with the htpasswd support program. For example:

AuthUserFile /WWW/Admin/.htpasswd

deny

deny from hostnames ...

The deny directive is used within a <Limit> section of an ACF. It affects which hosts are denied access to a directory. The hostnames can be any one of the following:

domain name

A domain name, like .ora.com. Hosts from that domain are denied access.

host name

A full hostname.

full IP address

The IP address of a host.

partial IP address

The first 1 to 3 bytes of an IP address, for subnet restriction.

`all`

Using the word all means that all hosts are denied access.

<Directory>

<Directory>...</Directory>

The <Directory> directive is a sectioning directive that identifies the directory or directories to which contained access-control directives apply. It is used to structure the global ACF, and cannot be used in a per-directory ACF. The start tag has the following format:

<Directory dir>

where dir is the absolute pathname of the directory, which may include wildcard characters (* and ?) to designate a set of directories.

<Limit>

<Limit>...</Limit>

The <Limit> directive is a sectioning directive that identifies which clients and users can access a directory. This directive applies to both the global ACF and per-directory ACFs. The start tag has the following syntax:

<Limit method1 method2 ...>

where method is one of the following:

`GET`

Allows clients to retrieve documents and execute scripts with the GET request method.

`POST`

Allows clients to use scripts and resources using the POST request method (mostly CGI programs).

The order, deny, allow, and require directives are the usual inhabitants of the Limit sectioning directive. Later versions of NCSA (1.5 and up) have three additional directives designed for the <Limit> section: referer, satisfy, and OnDeny.

<Location>

<Location>...</Location>

A sectioning directive for specifying directives that apply to a given URL. Basically just a more specific version of <Directory>.

OnDeny

OnDeny URL

For NCSA versions 1.5 and later, the OnDeny directive can be used in a <Limit> section of an ACF to redirect the client to another URL if access to the directory has been denied.

Options

Options options ...

Controls the degree of advanced features that you wish to allow on your server. One or more options may be listed on the Options line, separated by spaces. Valid entries are:

`None`

No features are enabled in this directory.

`Indexes`

Allows users to request indexes in this directory.

`Includes`

Server-side includes are enabled in this directory.

`IncludesNoExec`

Server-side includes are enabled in the directory, but the exec feature is disabled.

`ExecCGI`

Execution of CGI scripts is allowed in this directory.

`FollowSymLinks`

The server follows symbolic links in this directory.

`SymLinksIfOwnerMatch`

The server only follows symbolic links if the target file/directory is owned by the same user ID as the link.

`All`

All features are enabled in this directory.

The Options directive can be used in both the global ACF and in per-directory ACFs. There can be only one Options directive per Directory segment. If omitted, the default is:

Options All

order

order order

The order directive specifies the order in which deny and allow directives are evaluated within a <Limit> section. This directive is only available within <Limit> sections, but can be used on a global ACF or per-directory ACF basis. The order line can take one of the following forms:

`order deny,allow`

deny directives are evaluated before allow directives (this is the default).

`order allow,deny`

allow directives are evaluated before deny directives

order

order order

This setting means that any host appearing on the allow list is allowed, any host listed on the deny list is denied, and any host not appearing in either list is denied.

referer

referer allow|deny from URL

For NCSA version 1.5 or later, the referer directive can be used in a <Limit> section of an ACF to specify that a request in this directory must have originated from a specified location. The URL must use the service name (http:, etc.), and can be an exact match to a document name or use wildcards to designate a set of documents, directories, or servers.

require

require entity names ...

Specifies which authenticated users can access a given directory with a given method in a <Limit> section of an ACF. A require line requires that all of the appropriate Auth* directives are specified for the directory. entity is one of the following:

`user`

Only the named users can access this directory with the given methods. Each name is therefore a username that exists in the specified password file.

`group`

Only users in the named groups can access this directory with the given methods. Each name is therefore a group name that is listed in the specified group file.

`valid-user`

All users listed in the AuthUserFile (specified password file) are allowed access upon providing a valid password.

satisfy

satisfy all|any

For NCSA version 1.5 and later, the satisfy directive can be used in a <Limit> section of an ACF to control how access is handled when both allow and require directives are used (i.e., when both host and user/password authentication are set). The directive can take one of two values:

`all`

This setting means that a user must satisfy both the allow and require directives to gain access to the directory.

`any`

This setting means that a user must satisfy only one of the allow or require directives to gain access to the directory.

The following directives can also be used within the global ACF and per-directory ACFs as indicated:

DefaultType

Only per-directory ACFs

AddEncoding

All ACFs

AddDescription

Only per-directory ACFs

AddIcon

All ACFs

IndexIgnore

All ACFs All ACFs

ReadmeName

All ACFs

These directives are a subset of those allowed in srm.conf, and are described earlier in this chapter.

For the Apache server, other directory-specific configuration directives may be included in Directory sections or per-directory ACFs in addition to those listed above. A non-applicable directive should be unaffected.