Access Authorization About to be Ready
luotonen@ptsun00.cern.ch (Ari Luotonen)
Date: Mon, 4 Oct 93 16:36:40 +0100
From: luotonen@ptsun00.cern.ch (Ari Luotonen)
Message-id: <9310041536.AA27445@ptsun00.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Access Authorization About to be Ready
Access Authorization is in, and the new library version will be out
this week.
So this is how it turned out... Protocol is as it was decided in this
mailing list. This is all CERN server specific.
RULE FILE:
Two new rules, NO other changes:
defprot <template> <setupfile> [<uid>][.<gid>]
protect <template> [<setupfile> [<uid>][.<gid>]]
Neither of these passes, only sets protection, and
translation continues from the next rule.
"protect" protects absolutely -- if ACL doesn't
exist access is forbidden.
"defprot" rule sets the default protection, i.e.
if not explisitely protected by "protect" rule but
ACL exists this protection setting is used.
This is also used if "protect" rule doesn't provide
all the necessary protection information.
("fork" rule went salut!)
SETUP FILE:
Mask-Group user, @128.141.*.*, group@(131.*.*.*, *.cern.ch)
Authenticate Basic, Pubkey, KerberosV4, ...
Server-Id <password server name for Basic-scheme>
Passwd <password file for for Basic-scheme>
Group <group file for for Basic-scheme>
If "Mask-Group" doesn't exist all the connection are accepted.
Otherwise only people belonging to that group are allowed.
Access control list is consulted only after this succeeds.
Syntax of "Mask-Group" is as that of group definitions in
the group file.
"Authenticate" specifies valid authentication schemes.
If there is no "Authenticate", and "Mask-Group" contains
only internet addresses, e.g.
Mask-Group @128.141.*.*, @131.*.*.*, @*.cern.ch
only connections from those addresses are allowed, but
there is no other access authorization.
This is the only case where access is still allowed with
protect rule, but without access control list file.
GROUP FILE:
groupname: user, group, @address,
user@address, group@address,
(user, group, user, ...)@address,
user@(address, address, address, ...),
(user, group, user, ...)@(address, address, ...)
address may be either an IP number template (e.g. 128.141.*.*)
or IP name template (e.g. *.cern.ch).
IP address is checked first. Iff successful users group
membership is checked (recursively). During recursion
IP address must always match, e.g.
hackers: marca@*.uiuc.edu, ari@ptsun*.cern.ch, timbl@info.cern.ch
cern-hackers: hackers@*.cern.ch
marca can never get access into anything requiring cern-hacker
access because *.cern.ch and *.uiuc.edu are exclusive.
Only restriction is that addresses cannot be group names.
If someone wants this (strange) feature, I'll implement it.
IP address template matching is only implemented for IP
numbers -- I'm not sure if they even should be implemented
for domain names (I refer to the recent discussion about
DNS lookup deficiency).
ACCESS CONTROL LIST FILE:
<template> : get,put,... : user, group, (user,...)@(address,...)
Last field has equal syntax and semantics as group definition,
and it is translated in the context of group file.
PASSWORD FILE:
<username> : <crypt()'ed password> : <Whatever>
So understands directly unix /etc/passwd if someone
wants that.
FORKING:
If a stand-alone CERN server (-p or -a option) is
running as root or is started up with -fork option
it forks itself to serve all requests.
SET-UID AND SET-GID:
If a stand-alone server is running as root the child
always does setuid() and setgid() (as specified in
rule file by "defprot" and "protect" rules).
If server is lauched by inetd and is running as root
it doesn't fork but does setuid() and setgid() itself.
If uid or gid is not specified default is 65534 (nobody
and nogroup).
Server refuses to serve a request as root.
-- Salut, Ari --
\\\\Ari Luotonen//////
\\\\WWW Person//////
\\\\\\/\\\\\//////
\\\\//\\\\//////
\\////\\//////
\/\/\/\/\/\/