ChrisKnightsInterestingPostOnACLsAndZope

[Chris Knight]

Note: I've actually implemented a system that adopts the ACL "paradigms" in an
object persistence environment.  Specifically, it's a ACL layer on top of
Zope's database (ZODB).  I had implemented a similiar system using MySQL as the
persistent storage.  This system has had a WebDAV protocol interface layered on
top of it (thanks to the excellent work by Christian Scholz at
http://www.webdav.de for the interface.)


This project is now in "beta" here at Ames with a few other people developing
applications within this environment.  (I may push to have it open-sourced in
the future, but it may be a chore to get NASA to do so.)

> I recommend that we specify that groups are a list of users and or other =
> groups.  Group membership is recursive, but cyclic group membership is =
> not allowed.  This will allow for easier administration and =
> implementation.  I recommend leaving rule-based group membership out of =
> the spec.  I also think that we should mention that servers are allowed =
> to cache group membership for arbitrary lifetimes (for example the =
> lifetime of a connection or "session").  Flushing these caches is =
> implementation-dependent and outside the scope of the spec.

I agree that these recommendations make group administration much easier to
implement and support.  Having rule-based group definitions opens the door to
either implementing an arbitrary rule language or choosing an existing language
for rule implementation.  I don't know of any reasonable use for cyclic group
definitions.

A friend pointed me at the Andrew Filesystem access control spec, and I would
recommend we adopt the same paradigm.  Primarily, group membership can be
cached but ACLs cannot.  (So, if you have a security breach or some other
highly time-dependent access control changes, you alter the ACLs to give the
proper privileges and later perform group alterations.)

Unluckily, this AFS document was rather dated, anyone know how well this
paradigm has worked in practice?

> =B7         Deny rights:  The current spec doesn't specify what happens =
> when a user is a member of two groups, one of which grants access, and =
> the other which denies access.  We should specify that that right is =
> denied in this case (which is consitent with most other ACL =
> implementations)

That's how I implemented my system, denies take precidence over grants.

> =B7         Structure of an ACE:  Currently the draft specifies that an =
> ACE can grant access to a SET of principals.  This can make =
> implementations difficult, as the set of principals to which a right can =
> be granted is very large, whereas the set of rights that can be granted =
> is typically very bounded.  This makes it hard to flatten out (in a way =
> that can be regenerated), which must be done to evaluate and store =
> easily.  Most other ACL models I have seen restrict an ACE to a single =
> principal, and require that multiple ACEs be used to handle multiple =
> principals.  I think this will be much simpler to implement.  Also, I =
> think that a specific ACE should either grant or deny rights, not both.  =
> (This is similar to the java.security.ACL model).  We should also =
> specify that an ACL may not both grant and deny permissions to the same =
> principal.

This wasn't a problem in either my ZODB version nor for my MySQL version...But
then on the flip side I don't see a huge need to have multiple principals per
ACL...But it could become space-inefficient if you/users don't manage "groups"
properly.

As for grant or deny, I agree that in most cases there won't be a need to mix
them in the same ACE (and it is often harder to represent/store, since
[effectively] each right can have one of three states [grant/deny/undefined]).

> =B7         Rights:  The set of rights meaningful for a particular =
> resource should be based on the dav:resourcetype (the "class" =
> definition) for that resource.  Servers should keep a list of all rights =
> that a resourcetype defines.  For example, the "collection" resourcetype =
> should define "dav:createchild" and "dav:deletechild"-they shouldn't =
> apply to all resources.  If I wanted to define a resourcetype called =
> "Perl Script" I might want to define a permission type called =
> "gnu:execute" for that.  Note that since the rights naming is based on =
> XML, XML namespaces should apply here.

In my object system (described above) there is no distinction between
collections and non-collections.  (All objects can have "children", the only
notion of "containment" the system has.  Per my previous e-Mail to the main
WebDAV WG list, containment in my system is defined by the inheritance tree.
Needless to say, in my WebDAV interface, I've layered a new hierarchy [so that
each object only has one parent and there is the distinction between
collections and documents.])

> Servers may choose to implement this via inheritance, where the rights =
> defined by a parent class of resource would also be meaningful on =
> subclasses of that resourcetype, but the spec will not address this.

Exactly how I implemented it.
(The property inheritance tree == the "group" tree.)

> If an ACE names a right not defined by that resourcetype, it is ignored =
> for all purposes (so an ACL can be shared via inheritance across =
> heterogeneous resource types)

Certainly makes sense.