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.
<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.
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).
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.
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).
groupname: item, item, itemThe 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
mask-group
in protection setup file, and
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.setupIf 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
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/groupPassword 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).
Same server-ids on different machines are considered
different by clients (otherwise this would be a security hole).
KerberosV4 authentication is here only as an example;
it has not been implemented as part of the library.
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.
In this case you don't need the mask-group
in setup
file.
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.
.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,kennyIt 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