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

Charles Landau clandau at macslab.com
Thu Sep 18 10:52:15 CDT 2008


Jonathan S. Shapiro wrote:
> Please go back and re-read my original problem statement. If it was not
> clear, please say what needs refinement.

> On Wed, 2008-09-17 at 19:28 -0700, Charles Landau wrote:
>> On 9/12 at 9:06 pm Jonathan S. Shapiro wrote:
>>> Problem:
>>>
>>> Alice, Bob, Henry, Elmo, Oscar, and so forth are involved in a task
>>> that requires that all of them manipulate and modify some object
>>> graph. By "manipulate and modify", I do not mean merely that they
>>> modify the leaves of the graph. I mean also that they modify the
>>> structure of the graph itself. It is required that the parties be
>>> able to have different access rights on different subgraphs.
>> Some thirty messages later, I still don't have clarity on who gets to 
>> decide who has access to what.
> 
> It doesn't matter to the problem at hand. There is a party who decides.
> For this example, we can call them "God". :-) 

I think it does matter. Suppose that "God" decides that Alice should 
have access to object L, while Bob should not. Further suppose Alice and 
Bob can communicate, and Alice wishes to proxy L to Bob. This is a 
problem that neither capabilities nor ACLs can solve.

> The challenge problem does
> posit that the permissions may change. It does not specify mechanism for
> that change.

I take you to mean, the challenge problem does not specify a *policy* 
for changing permissions.

Since capabilities are all about controlling permissions, and you are 
not specifying the requirement for that, perhaps this list is not the 
appropriate venue for this discussion.

>> For example, if Oscar has read-only access to leaf object L, and stores 
>> a reference to L in node/directory D, to which Henry also has access, is 
>> it possible that Henry could thereby acquire write access to L? In other 
>> words, can Oscar grant more authority than he himself has? If so, what 
>> security properties can be assured?
> 
> Yes to all of the above, including the last. 

The last question doesn't admit to a "yes" answer.

>> do you want to have a 
>> kernel that handles both (twice as big), or do you want to build one on 
>> top of the other (inefficiency)?
> 
> I don't buy "twice as big". 

Does the proof of correctness scale linearly with the size of the system?


More information about the cap-talk mailing list