[cap-talk] In Defense of Identities - really not

[Jed at Webstart]

At 08:27 AM 12/6/2006, Jonathan S. Shapiro wrote:
>On Tue, 2006-12-05 at 16:52 -0800, Jed at Webstart wrote:
> > I happen to be in the loop (as a sysadmin)
> > when people try to apply the ACL approach to access control.  The basic
> > problem with an ACL approach is the question of who controls the
> > ACL?
>
>Another way to say this is that the ACL object itself is not
>first-class, and one of the pragmatic deficiencies of ACLs is that the
>ACL objects themselves stand outside the permissions model. It's a
>reductio failure of sorts.

Right.

>However, we should be clear that this is not a deficiency in ACLs per
>se. It is quite possible to implement an ACL system wherein the ACL
>objects are first class. Xanadu and OpenCM both do so.

I don't know how Xanadu and OpenCM handle this situation, but I
argue that if they do so effectively then the ACL system takes on
the semantics of an object-capability system.  Namely if I have
a permission then I can add you to the ACL.  To my thinking
that then 'just' becomes an implementation of a capability system.

> > The only reason an approach like that used in Unix (e.g. groups)
> > even begins to work (at least in our environment - I'll be interested
> > to hear from others in this regard) is that resource owners can enable
> > group access or world access without the need to get a sysadmin
> > involved.  If there are reasonable groups available then delegation to
> > at least the granularity of a group is possible by the resource
> > owner.  As Mark Stiegler points out, in reality most sharing is done
> > through the network, usually by repeated (if necessary) copying.
> > How much access control is that?
>
>If you are saying "UNIX only works because groups provide an escape
>hatch", then I tend to agree. In OpenCM, where the "group" object is
>first-class, we avoid much of the need to get the administrator
>involved.
>
>I would add that it also works because changes to groups are rare. That
>is: the members of a group may change frequently, but the organization
>of the groups themselves reflects the human organization and process,
>and that changes very slowly.

Hmmm.  Well of course "slowly" above is a relative term.  I agree that
new group semantics change relatively slowly.  That is new groups
tied to projects or organizational needs tend to arise rather
slowly - though I argue that is at least partly because the mechanism
has so much administrative overhead.  At LLNL where users could create
their own groups such groups were more dynamic.  The other side
of group changes however is the change in people in the groups.
We see constant flux in our groups at NERSC.  I manage an LDAP
server and see such changes go by in my logs.

>This is true to such a degree that every time I form new groups in
>OpenCM I have to use "cm help" to remember the syntax. I don't have any
>trouble remembering how to add a user to a group (well, I get the
>argument order mixed up, but that's not "real" trouble).

My experience is similar and was even in the old LLNL system.

> > This system worked terrifically.  It was all user managed and
> > no sysadmins had to get involved.  If I want to start a group
> > collaboration I can create a new project directory out of
> > whole cloth and give the members of the group permission
> > to access it....
>
>We've seen a similar effect in OpenCM, though our mechanism is less
>robust. In OpenCM, every user has a directory hierarchy within the
>store. There is a special group called "everyone" that is fabricated at
>store creation time. The everyone group is special in that (1) the add
>user appends an entry to "everyone" whenever a user is added, (2) the
>add user creates an initial binding to everyone in each user's home
>directory.
>
>To share state, I can create a directory that is writable to everyone.
>
>The deficiency here relative to the system you describe is that our
>write permissions are too coarse -- we don't currently distinguish
>between directory insert authority and directory delete entry authority.
>
>Aside: none of this actually relies on the everyone directory; this is
>purely a convenience. It is perfectly possible for me to send you a
>sturdy object id by email that names my user object, and you can add me
>to a group that you have created.

I look forward to the day when we have such semantics readily available
on the Internet - with responsibility tracking ;-)

>The distinction about add vs. delete in directories, and the deficiency
>in OpenCM here, is obvious, but I only just noticed. The other useful
>distinction is that authority to write an object should not necessarily
>convey authority to modify the object's ACL.

Of course I argue that any permission to an object should convey the
permission to modify the object's ACL - exactly so as to delegate
that permission to another subject.  Otherwise you force subjects into
the proxy role when they need to delegate.  If you deal with the
permission to modify an ACL in that why then I argue that you have
created object-capability semantics with an ACL implementation,
as indeed I did in DCCS (which I think is worth considering in
this regard), and as I described in:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

>The original OpenCM design
>did not distinguish these write authority. The later version (which is
>finally getting cleaned up now) does.
>
>The directory example is going to force me to reconsider whether we
>handled the ACL issue well. I'm beginning to think that we may want to
>re-open it.

Sigh!  Even flap in implementations?  Is it any wonder our systems don't
climb in market leadership?  I argue that if your ACL implementation doesn't
supply object-capability semantics for delegation then your design does
indeed need to be re-opened!

I look forward to a defense of any alternative semantics.  I will of
course focus on how cooperation via delegation can be done in an
alternative system of communicating permissions.

--Jed  http://www.webstart.com/jed-signature.html



--Jed http://www.nersc.gov/~jed/