[cap-talk] "ACLs don't" paper rejected from Oakland 09

[Toby Murray]

On Mon, 2009-02-02 at 17:05 +0000, David-Sarah Hopwood wrote:
> > Note that the different "outputs" here are authority not permission.
> 
> No. As the paper says for the example of section 2.3,
> 
> # In capability transfer, the User's attempt to construct a compile message
> # specifying write permission to log.txt is rejected by the reference
> # monitor [...]
> 
> Sending the compile message is an individual operation that the ACL system
> allows (because "log.txt" is just a string in that case), and the capability
> system does not (because log.txt has to be specified by a write capability),
> in the same access matrix state.
> 
> That is, the capability system is performing an access check, based on the
> direct permissions of the User at the time of the message send, that is not
> performed for the equivalent operation in the ACL system. There is no sense
> in which they can be construed as equivalent.

We're using different definitions of permission. I'm using permission as
"the ability to directly perform an operation on another party". You're
using it as "ability to directly perform an operation on another party
passing specific parameters." 

Under my definition, the user's permissions in both cases are:
{Compiler}, the compiler's permissions in both cases are {Logfile}.
Hence, under this definition, there is no difference in permissions.

In the ACL case, User's permissions are {Compiler.compile(x) | x denotes
any string}. In the capability case, User's permissions are
{Compiler.compile(Compiler)}. How do we know that these are, in fact,
different? We're not comparing apples with apples, since the text
strings have no meaning in the ACL case until interpreted by the
compiler. Hence, I'd argue that one cannot make an inequivalence claim
on this evidence alone. It is the difference in the User's authority
that can be compared between the two cases and it must be this
difference on which an inequivalence is judged.

 

Cheers

Toby