 |
Chapter 24 |  |
|
Chapter 24 | |
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 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.
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.
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).
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.
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.
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 {
protection
setup
info
}
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.
