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

Kevin Reid kpreid at mac.com
Wed Sep 17 06:16:36 CDT 2008


(Replying to an old message)

On Sep 15, 2008, at 13:09, Jonathan S. Shapiro wrote:

> The question that interests me at the moment is how to render a system
> already built on ACLs survivable by applying capability intuitions  
> to it
> *without* ripping out the API that applications already expect. Like  
> it
> or not, that means that I'm committed to ACLs in this thought  
> experiment
> (though perhaps only in hybrid form).
...
>
> Summary:
>
>  1. Revocation of capabilities must be possible on a per-principal
>     basis.
>
>  2. Revocation of capabilities must not depend on the path by which
>     they arrived in my hands.
>
> While it is possible to build membrane systems that automate the
> capability exchange protocols required to meet both requirements, the
> only thing one has achieved in the end is to replicate ACL systems
> inefficiently.

I don't see how any system could be both externally interpretable as  
an ACL system, and not arguably an 'inefficient replication' of an ACL  
system. I'm interested in solving this problem, but it seems to me  
that these two requirements might be mutually contradictory.

Given your stated summary, the system which comes to mind is this:

Each principal holds references to the graph via a membrane specific  
to it. The membrane holds a table of nodes and access levels; when a  
cap passes from the graph to the principal, that access level is  
provided through a facet; in the other direction, the cap is unwrapped/ 
converted to the 'base' state that lives in the graph.

Note that this system does not store a table of principals in any  
nodes, and does not communicate any "principal IDs" to the nodes; as  
such, it is arguably not an ACL system.

This meets your first summary requirement, as the membranes may be  
individually controlled, and your second, as the membranes unwrap as  
references return to the graph, so they do not stack.

Do you consider this a (replication of an) ACL system?

Does it meet your original requirements?

Given that you are interested in applying capability intuitions to an  
ACL system, why do you care that a capability implementation (or  
interpretation) of the system happens to mirror the ACL-system  
structure closely?

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>




More information about the cap-talk mailing list