[E-Lang] Java 2 "Security" (was: Re:
WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
Mark S. Miller
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.