Protected CERN Server Setup

Access can be restricted according to user name, internet address, or both. Access control can be tree-level, file level, or both.

Password File

If user-wise access control is used there has to be a password file listing all the users and their encrypted passwords.

Note: Unix password files are understood by CERN daemon (but not vice versa). However, Unix users are in no way connected to the WWW access authorization.

htadm

Password file can be maintained by htadm program which is a part ot CERN daemon distribution. htadm recognizes currently (version 2.13 and newer) the following options:
-adduser option:
    htadm -adduser <passwordfile> <username> <password> <realname>
adds a user into the password file (fails if there is already a user by that name).

-deluser option:
    htadm -deluser <passwordfile> <username>
deletes a user from the password file (fails if there is no user by that name).

-passwd option:
    htadm -passwd <passwordfile> <username> <password>
changes user's password (fails if there is no such user).

-check option:
    htadm -check <passwordfile> <username> <password>
checks user's password (fails if there is no such user). Writes either Correct or Incorrect to standard output. Also indicates password correctness by a zero return value.

If <password> or even <username> is missing in either of the previous cases they are prompted interactively. <passwordfile> must be always specified. Missing real name is also prompted when adding a new user.

Note: Do not use colons in passwords (this restriction will be removed in version 2.13). Also, passwords should not be longer than 8 characters (this is a restriction from linemode clients using C library function getpass() to read the password -- there is no other cause for this restriction; the maximum hardcoded password size is actually 32 characters, and if you only use GUI or other clients that are able to read this long passwords, feel free to use them).

WARNING: Do NOT use htadm to add new users to the actual Unix password file /etc/passwd, entries written by htadm are missing some necessary fields to Unix.

Note: htadm destroys the password from command line as soon as possible so that it is very unlikely to see somebody's password by looking at the process listing on the machine (with ps, for example).

Group File

Group file contains declarations of groups containing users and other groups, with possibly an IP address template. Group declarations as viewed from top-level look like this: 
        groupname: item, item, item
The list of items is called a group definition. Each item can be a username, an already-defined groupname, or a comma-separated list of user and group names in parentheses. Any of these can be followed by an at sign @ followed by either a single IP address template, or a comma-separated list of IP address templates in parentheses. The following are valid group declarations: 
        authors: john, james
        trusted: authors, jim
        cern_people: @128.141.*.*
        hackers: marca@141.142.*.*, sanders@153.39.*.*,
                 (luotonen, timbl, hallam)@128.141.*.*,
                 cailliau@(128.141.201.162, 128.141.248.119)
        cern_hackers: hackers@128.141.*.*
If an item contains only IP address template part all users from those addresses are accepted (e.g. cern_people above). Note the last two declarations: cern_hackers group is made up of the hackers group by restricting it further according to IP address.

Group definition can be continued to next line after any comma in the definition. Forward references in group file are illegal (i.e. to use group name before it is defined).

Group definition syntax is valid not only in group file, but also in

Rule File

Typically you protect a tree of documents by protect rule in rule file, and specify authorized persons and IP addresses in the protection setup file or access control list file: 
        protect /very/secret/*  /WWW/httpd.setup
If there are Unix file system protections set up so that there is no world read-permission the daemon naturally has to run as the owner or the group member of those files.

However, if there are protected trees owned by different people this doesn't work. In that case the daemon has to run as root, and the user and group ids have to be specified in the protect rule, e.g.: 

        protect /kevin/secret/*	  /WWW/httpd.setup1  kevin.www
        protect /marcus/secret/*  /WWW/httpd.setup2  marcus.nogroup

Protection Setup File

Each protect rule has an associated protection setup file. It specifies valid authentication schemes, password and group files, and password server-id: 
        authenticate  Basic, KerberosV4
        server-id     OurCollaboration
        passwordfile  /WWW/Admin/passwd
        groupfile     /WWW/Admin/group
Password server id needs not be a real machine name. It's only purpose is to inform the browser about which password file it is using (different protection setups on the same machine can use different password file and that would otherwise confuse pseudo-intelligent clients trying to figure out which password to send).

Note 1: Same server-ids on different machines are considered different by clients (otherwise this would be a security hole).

Note 2: KerberosV4 authentication is here only as an example; it has not been implemented as part of the library.

Protecting Entire Tree as one Entity

If you want to control access only to entire trees of documents and don't care to restrict access differently to individual files, it suffices to give a mask-group in setup file (and you don't need any ACL files): 
        mask-group	group, user, group@address, ...
Group definition has the same syntax as in group file.

Protecting Individual Files Differently

When each individual file needs to be protected separately you should use an ACL (access control list) file in the same directory as the protected files. After that no file in that directory can be accessed unless there is a specific entry in ACL allowing it.

In this case you don't need the mask-group in setup file.

Restricting Access Even Further

There may be both mask-group and an ACL, in which case both conditions must be met. This is typically used so that mask-group defines a general group of people allowed to access the tree, and ACLs restrict access even further.

Access Control List File

ACL file is a file named .www_acl in the same directory as the files the access of which it is controlling. It looks typically something like this: 
        secret*.html : get : trusted_people
        minutes*.html: get : secretaries
        *.html : get : willy,kenny
It is worth noticing that all the templates are matched agaist (unlike in rule file where translation of rules stops in pass and fail.. So in the previous example all the HTML files are accessible to willy and kenny, even those matching the two previous templates.

The last field is just a list of users and group (possibly at required IP addresses), and in fact this field is in same syntax as group file.

When PUT method will be implemented it can appear in the middle field separated by a comma from get: 

        *.html : get,put : authors

AL 12 December 1993