Webmaster in a Nutshell

Previous Chapter 24
CERN Server Configuration

24.7 Access Control Configuration

The access control scheme used by the CERN server is a bit confusing, but it allows you to set control access to either directories or specific files based on the client's host and/or username/password authentication.

The access control scheme begins in the httpd.conf file with the Protect directive. This directive specifies a directory or group of directories to protect, and associates them with a specific protection setup file. The protection setup file specifies valid authentication schemes, the password and group files to be used for authentication, and, optionally, user, group, and host access controls for all documents in the protected tree.

When a request for a document in a protected directory is received, the server looks for a file in the directory named .www_acl. This is the access control list file (ACL). It designates which files in the directory may be accessed, with what methods, and by whom. It uses the password and group files and masks specified in its associated protection setup file to carry out access authorization.

Password File

Password files contain valid usernames and encrypted passwords for user authentication on your server. They can be created with the adm program that comes with your server software.

Password files are similar to the UNIX password files, but there is no correlation between valid users for your server and registered users on the UNIX machine.

Group File

The group file lists the valid groups and their members for use with access control to your system. Group members can be declared by username, previously defined group names, and host address templates. Each group declaration looks like this:

groupname: item1, item2 ...

Each item uses group definition syntax to declare members of the group. With this syntax, each item may be specified as:

IP-address templates not attached to user or group names mean that all users from the specified IP are valid group members. When attached to users or groups, users are only valid from those IPs. Users and groups with no attached IP template are valid from any IP.

IP-address templates are IP addresses that may use a wildcard (*) for any part of the address for subnet restriction.

Here is a sample group file:

humans: mike, joel
bots: servo, crow, gypsy, cambot
mads: forrester, frank@198.112.*.*, pearl
crew: humans, bots, @198.112.108.*
deep13: mads, larry@198.113.*.*,
        (gerry, sylvia)@198.114.*.*
mst3k: crew, deep13, (glenn, jperkins, janpan)@(198.*.*.*, 36.108.*.*)

Group definitions can be broken across a line following a comma in the definition list.

The group definition syntax described here is also used for GetMask lines in protection setup files and for the last field of ACL entries.

Additionally, there are two predefined group names that can be used in those areas. They are:


All users that have an entry in the password file. Users is equivalent.


No restrictions are placed on access; all users are allowed without authorization. Anonymous and Anyone are equivalent.

Protection Setup File

A protection setup file is required for each protected directory or tree designated by the Protect directive in httpd.conf. The Protect directive specifies the pathname of the protection setup file that its directories will use. Here is a sample protection setup file:

AuthType      Basic
ServerId      SatelliteOfLove
PasswordFile  /WWW/Admin/passwd
GroupFile     /WWW/Admin/group
GetMask       All
ACLOverRide    On

The GetMask directive is optional. All other directives must be included.


AuthType type

Indicates the type of authentication to use. Basic is most common. Other methods may be used if the server supports them.


ServerId name

This directive does not need to specify the server's actual machine name. It can be any string and is used to inform the client what password file it is using (in case the user has multiple usernames on different parts of the server).


PasswordFile filename

Specifies the absolute pathname of the password file.


GroupFile filename

This directive specifies the absolute pathname of the group file.


GetMask list

If you want to set general restrictions on all the documents in a protected directory tree, you can set them in the protection setup file with GetMask. You can specify allowed users, groups, or IP addresses with the group definition syntax. This directive is optional.


ACLOverRide On|Off

Protection setups files normally do not allow any access outside of what is set in a GetMask directive. To override the GetMask rules, you can set ACLOverRide to On. The default is no overrides by the ACL.

Access Control List File

To control per-file access in a protected directory, you need an access control list file (ACL) named .www_acl in that directory. Each directory in a protected tree needs its own .www_acl for file-level access control. In fact, you cannot have a .www_acl file in a directory that is not designated in a Protect directive in the configuration file.

Each line of an ACL looks like this:

file : methods : groups

The first field contains the name of the file to be controlled. It can match a filename exactly or use the wildcard (*) to designate a group of files.

The second field lists the request methods allowed on the file. You can specify GET, or POST, or both with GET,POST .

The last field lists the users that are allowed access to the file. You can use users listed in the password file, groups listed in the group file, or IP-address templates. Each item should be separated by a comma. Group definition syntax can be used in this field.

Here is a sample .www_acl file:

*.html : GET : mst3k,torgo
cgi-*.pl : GET,POST : crew,mads
secret*.html : GET : bots,frank

There is no order to rules matching here. In the example, user torgo, who is not a member of the bots or mst3k groups, is allowed to access the "secret" files.

Access Configuration Directives

Protect expression setup_file uid.gid

Protect expression setup_file uid.gid

In the server configuration file (httpd.conf), the Protect directive specifies a set of directories to be protected and gives the name of the protection setup file to be used for access control in those directories. The directive looks like this:

Protect /WWW/mst3k/* /WWW/Admin/httpd.setup

This sets access control for all directories under /WWW/mst3k. The directory names must be an absolute pathname, and may use the wildcard character (*). An optional third argument can specify the user and group name (separated by a period) of the protected directory's owner, if the permissions are different from the server daemon's. For example:

Protect /WWW/mst3k/* /WWW/Admin/httpd.setup cambot.mst

User cambot in group mst owns the directories.


Protection name

Beginning with version 3.0, the protection setup file information can be included in the server configuration file instead of in an outside file. You use the Protection directive for this, and syntax looks like:

Protection name {

A Protect directive can then use the name of the Protection directive to specify its protection setup information.

You can save a step in the process by simply tacking the protection setup section onto the Protect directive where you would normally name the setup file. For example:

Protect /WWW/mst3k/* {
    UserId        cambot
    GroupId       mst
    AuthType      Basic
    ServerId      SatelliteOfLove
    PasswordFile  /WWW/Admin/passwd
    GroupFile     /WWW/Admin/group
    GetMask       all

Each Protection section uses the same directives used in a regular setup file. Two additional directives can be used here to specify the user and group ids of a protected directory when they differ from those of the server daemon: UserId and GroupId.


UserId user

Specifies the user name of the directory owner.


GroupId group

Specifies the group name of the directory owner.

Previous Home Next
Directory Indexing Book Index Netscape Server Configuration

HTML: The Definitive Guide CGI Programming JavaScript: The Definitive Guide Programming Perl WebMaster in a Nutshell
Hosted by uCoz