rwx in ACLs (was Re: extattr in-kernel interface)

[Robert Watson]

On Tue, 18 Apr 2000, Ilmar S. Habibulin wrote:

> > [1] I use WinNT as an example because it is a available/visible.
> Why not to look at Novell or UNIX distributed filesystems (coda,afs,dfs)?

I'm not too familiar with Novell or DFS, so can't comment on those, but
have used AFS fairly extensively, and worked with the Coda group for a
while so can also comment on that :-).

The AFS and Coda ACL structures are almost identical (if not identical)
and the group behavior is very similar.  There are some differences from
the perspective of cross-realm behavior (Coda doesn't do cross-realm) but
in many senses they can be treated as the same mechanism.

In AFS, ACLs are assigned only to directories.  An ACL may consist of
positive and negative entries.  Subjects may be users, groups, or the
somewhat nebulous system:anyuser and system:authuser values.  Permissions
include:

w	May write the files in the directory
r	May read files in the directory
i	May insert new files in the directory
d	May delete files from the directory
k	(deprecated) may hold locks
a	May administer the ACLs on the directory
l	May list the contents of the directory

(It's been a little while, so forgive any minor inaccuracies or ommisions
:-).

Accesss to files within the directory are controlled by the directory ACL. 
Directories and files do not have owners.  Although there is an advisory
field which is used to store the owner viceid, it is not used for access
control.  Having the "a" right on a directory is functionally similar, as
it allows the holder to modify the ACL on the directory as they see fit.
Files have some advisory flags (read/write, executable, and so on) but
they are not conditional on the subject, and are overriden by the
directory ACLs.  In AFS, quotas are managed per-volume, so the no-owner
limitation does not present a serious limitation from that perspective. 
When a subdirectory is created, I believe it inherits the rights on teh
parent directory.  Extensive hard linking is prohibited in AFS -- I
believe to files in the same directory or volume, but would need to check
that first.  In AFS, users may maintain their own groups for the purposes
of access control, allowing the ACLs to be more expressive.  Groups are
also affected by a limited sort of ACL indicating who may control/list the
contents. 

This model has a number of benefits and downsides.  The benefits include a
conceptually simple and intuitive access control model, as well as the
simplification that only directories have rights, making it far easier to
manage, as well as encouraging the sorting of files based on the types of
rights associated with the file.  Individual management of ACLs in a
universal ACL namespace is extremely useful.

Downsides include a lack of ownerhip of files from an
auditing/accountability perspective, incompatibility with the UNIX model
limiting the usefulness of some traditional tools for viewing and managing
permissions (ls, tar, chmod ...), and the inability to express policies on
the granularity of individual files. 

I personally find the AFS model very appealing, as it combines relative
simplicity with a great deal of flexibility.  The concerning aspects are
the lack of interoperability, the reliance on hard links being limited in
scope, and the availability of a group management model.  The ACL
infrastructure currently in the FreeBSD kernel defines syntax but not
semantics for ACLs, and should be flexible enough to hold POSIX.1e ACLs as
well as Novell and AFS ACLs.  The semantics are defined by the underlying
file system--currently no file systems in the base system make use of the
ACL APIs.  I have experimental code that introduces POSIX.1e ACL semantics
over extended attributes on FFS, but it's not really in distributable
state.  I agree with Jon's observation that the limitations of the rwx
semantics are extreme, and have been pondering implementing both the NT
semantics and AFS semantics as loadable modules, as both would be useful
in a number of environments.  Introducing NT-style ACLs is particular
appealing for those replacing NT boxes with FreeBSD/Samba boxes due to
cost or management concerns.

The Take/Give model is an interesting one, especially the two-way
handshake properties (and auditing connotations), but I'd like to see some
more discussion of the relative benefits of various ACL models.  We're
currently in a position to start experimenting with some of this--I'll try
to get my experimental code into more useful shape in a week or two and
people are welcome to try various models out and see if they run into
limitations in daily use :-).  Most of the trusted UNIX systems I've
looked at just do a natural extension of the rwx model without introducing
new permissions.  The POSIX.1e spec does not prohibit adding new
permissions while retaining compliancy with the semantics implied by the
spec.

  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 trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message