[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

Mark S. Miller markm@caplet.com
Mon, 29 Jan 2001 00:15:38 -0800

At 04:52 PM Friday 1/26/01, David Wagner wrote:
>Mark S. Miller wrote:
>>I think everyone's been missing the more important way in which this example 
>>is broken -- the identity of the "you" in "you can hand off just read 
>>permission".  It's only root or the owner of file, not everyone who *has* 
>>read permission.  This isn't delegation, it's simply ACLs.
>I can't agree.  This may be a limitation of Unix, but it is
>not fundamental to ACL's.  Don't confuse accidental limitations
>of implementations with fundamental limitations of the concept.
>I claim it is trivial to extend the Unix OS to allow anyone who
>has read permission to delegate read permission to anyone else.
>Imagine we had a delegate() syscall, [...] there's no reason that you can't
>implement this type of functionality on an ACL system.
>[...] There's nothing
>inherent in the notion of ACL's that prohibits supporting delegate().

David, I either disagree, or we're using terms to mean different things.  
Could you explain what you mean by ACLs?  Or point at a definition you 
accept?  If you'd like to start with the Lampson "Protection" paper, that'd 
be fine with me.

To me, if you add your delegate construct to an ACL system, the resulting 
system certainly can delegate (as that's the primitive you added), but it is 
no longer an ACL system.  As we discussed in your office, ACLs vs 
Capabilities cannot simply be about where the permissions stored.  This is 
just implementation, not semantics.  If you wish, I can explain a full 
implementation of an E-like pure capability language in which all 
permissions records (ie, who may invoke whom) are stored with the invokee 
rather than the invoker.  Even though it uses an ACL representation 
internally, it only has capability semantics, and no ACL semantics.  
Surprisingly, it's probably less than 1/100th the performance of the natural 
implementation, and is definitely only a constant factor slowdown.

I bet I could likewise implement an ACL semantics using clist data structures.

In order for ACLs vs Capabilities to be a semantic difference, they must be 
defined in terms of how the permission to change permission is aggregated, 
when such permissions to change permissions are held by mutually suspicious 
parties.  Your delegate primitive, to my mind, violates the semantics of 
permissions-change that defines ACLs.