[cap-talk] In Defense of Identities - not

[Jonathan S. Shapiro]

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.

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.

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

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

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

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

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100