[cap-talk] More Heresey: ACLs not inherently bad

[Jed Donnelley]

At 06:03 AM 9/19/2008, Jonathan S. Shapiro wrote:
>On Thu, 2008-09-18 at 17:26 -0400, Sandro Magi wrote:
>...
> > When creating a principal, we communicate with the ACL service through a
> > management facet; creating a principal returns a capability with a
> > protected payload naming that principal (call it an ACL key).
>
>This is definitely a feasible way to go.

An unworkable way to go - if I'm understanding it right.  With such
a mechanism every time there is a request, one of these "ACL key"s must
go along to authorize access.  If a process/active object wishes to
send the authority to access a file to a compiler deputy, how can it
do so without sending the ACL key along?  If it does so then the
compiler server can act with that principal authority.

We came perilously close to such a disaster in our NLTSS work.
We had an "account" capability that was used when creating new
objects (files, processes, directories) so that the "user" who
created the object could be charged (accounted) for the resources
used by the object.  Unfortunately even just this much divided
services into those trusted to do accounting and to therefore
not abuse account capabilities and those that weren't.  If I
wanted to collect account capabilities I could simply create
a new type of object - e.g. a semaphore - and require that an
account capability be sent in when it was first created - as
with files, processes, and directories.  I could collect such
account capabilities and use them to create whatever I wanted
- with the charges going to some other user.

Not a good situation - but one that we were able to deal with
practically.  It seems to me what has been suggested above with
the "ACL key" is significantly and impracticably worse as it
is explicitly used for access control.

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