[Chapter 23] 23.3 Access Configuration--access.conf
Author: Stephen Spainhour and Valerie Quercia
Date: Fri Aug 29 18:23:00 1997

#

| Chapter 23 Apache and NCSA Server Configuration |

## 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.

Resource Configuration--srm.conf |  | CERN Server Configuration