AFS ACL Semantics (was: Re: ACLs 0.1 for FreeBSD 3.3-RELEASE)

[Robert Watson]

On 29 Nov 1999, Assar Westerlund wrote:

> Robert Watson <robert at cyrus.watson.org> writes:
> > > So I ported it to -current (and fixed some nits at the same time).
> > > But now that machine doesn't seem to come back up and I don't have
> > > physically access to it. :-(  But I should be able to send you the
> > > code hopefully later today or tomorrow.  Next step is adding support
> > > for vop_{get,set}acl to arla :-)
> 
> The kernel patches are at
> <http://www.sics.se/~assar/freebsd-patches/acl-current-19991129.gz>
> 
> I'll also make diffs incorporate the library and the user-level
> programs available at a URL close to that.

Sounds great.  Hopefully I'll get a crash machine up to -CURRENT this
evening and can apply your patches.  Gotta get over that kernel build
hump, if I recall -- unforutnately at my current location I only have
adialup line, so the cvsup could take a while :-).

> > Yes -- this was a change I was making over the DARPA ActiveNets workshop
> > and lost track of, as I didn't have a crash machine with me.  I guess the
> > best thing to do would be to get your version committed to -CURRENT, and
> > then I can resync on -CURERNT as my development tree and continue work
> > from there?
> 
> I think so.
> 
> > I feel two directions of pull here--the first is to produce as
> > near-POSIX.1e implementation as possible to maximize the chances of
> > portability and consistency across platforms; the other is to maximize
> > what I think of as the most desirable functionality, which approximates
> > what Coda and AFS use (directory-only permissions, and a bit more specific
> > than read/write/execute).  For the implementation, I went with
> > almost-exactly-POSIX, and feel we should probably do that for local file
> > systems, but that the issue of introducing Coda/AFS permission sets into
> > the interface, as they are permitted by the draft, is an interesting one
> > and should be looked at in detail.
> 
> I'm more interested in getting something useful (and somewhat
> generic).  I haven't given any thought as to have to map AFS ACLs into
> Posix ones.

My goal was to try and retain the POSIX.1e syntax while allowing more
flexible semantics for file systems with their own semantics.  There is
the issue of sorted ACLs which may differ with semantics, but we could
build that into the sort routine to recognize ACLs with AFS components.
This will probably make more sense once you've had a chance to read the
spec (URL below) which talks about their goals.  Essentially, I maintain
the ACLs in a sorted format to optimize evaluation speed -- the entries in
the ACL are sorted in the interpretation order for their access control
check, and the sorting occurs in userland (the kernel will reject the
submission of unsorted ACLs).

Implementation of the access control check occurs in the underlying file
system, although I provide some default routines that file systems might
use to provide consistent POSIX.1e semantics, if they desired.  AFS ACLs
could either look like POSIX.1e ACLs (i.e., use the same uid namespace and
qualifier type/tag), or they could use their own tag (ACL_TYPE_AFS) and
use the AFS viceid space, keeping the two independent, and meaning that
AFS ACLs submitted would not have to follow the sorting constraints.

> > If you don't have a copy of the spec, we should get a copy to you.  I
> > believe Winni put a copy online and posted to bugtraq a while back, and
> > that it is off of his POSIX.1e page?  We have permission from IEEE to
> > redistribute it as long as new downloaders agree not to redistribute it
> > themselves, the normal "don't blaim IEEE if it breaks your life", etc,
> > etc.
> 
> I don't have the spec and didn't find it at Winni's page either.

I guess he never linked it off the main page.  Here's the URL he posted to
the posix1e mailing list a few months ago:

  http://www.guug.de/~winni/posix.1e/download.html

.1e is the API and semantics discussion, .2c is the command line
utilities/support stuff.  Both specs also contains descriptions of their
auditing API (work in progress between SRI and myself), capabilities and
mandatory access control (work in progress by Ilmar), and also information
labels (being ignored by everyone).  There's also my POSIX.1e mailing list
which has developers from various communities participating (Linux,
SGI/IRIX+SGI/Linux, FreeBSD) and discussing corss-platform and
implementation issues.  To subscribe, send email to
majordomo at cyrus.watson.org with "subscribe posix1e" in the body; the
posting address is posix1e at cyrus.watson.org.  Courtesy Aleph1, there is an
archive on www.securityfocus.org which goes back a couple of months -- I'm
working on getting him back messages but haven't gotten around to it yet
(having problems extracting message IDs from my Cyrus server); I have an
IMAP-based archive available via anonymous imap on cyrus.watson.org,
folder lists.sec.posix1e.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message