Access Authorization About to be Ready (Ari Luotonen)
Date: Mon, 4 Oct 93 16:36:40 +0100
From: (Ari Luotonen)
Message-id: <>
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.


	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!)


	Mask-Group	user, @128.141.*.*, group@(131.*.*.*, *
	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.*.*.*, @*

	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.


	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. *

	IP address is checked first. Iff successful users group
	membership is checked (recursively). During recursion
	IP address must always match, e.g.

	    hackers: marca@*, ari@ptsun*,
	    cern-hackers: hackers@*

	marca can never get access into anything requiring cern-hacker
	access because * and * 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).


	<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.


	<username> : <crypt()'ed password> : <Whatever>

	So understands directly unix /etc/passwd if someone
	wants that.


	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.


	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//////