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

[Jonathan S. Shapiro]

On Wed, 2008-09-17 at 19:28 -0700, Charles Landau wrote:
> On 9/12 at 9:06 pm Jonathan S. Shapiro wrote:
> > Arrggh. Let me try this again.
> > 
> > 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". :-) The challenge problem does
posit that the permissions may change. It does not specify mechanism for
that change.

To give you a more serious response, I agree that there are issues
concerning update of the permissions and authority to perform that
update that are real and valid. But that's a second problem. At the
moment, we can't even figure out a strategy that works even if we had
that worked out.

But if it helps, consider that *MANY* source code repositories want to
implement an ACL notion over different areas of the tree (e.g.
documentors shouldn't muck with code), and that example may be
interesting because the selection/rejection criteria are *not*
hierarchical.

> 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. However, the scenarios I
envision do not include ones in which an arbitrary party can insert an
*arbitrary* capability into the graph. As a practical matter, I would
expect a copy to be involved in the case you are considering.

> Without a clear statement of the problem, I don't see how we can help 
> you design a solution.

Please go back and re-read my original problem statement. If it was not
clear, please say what needs refinement.

> If the problem statement is "it has to be Unix compatible", it's not 
> surprising that Unix is the most efficient solution. The issue in my 
> mind is, do you want to have *both* Unix ACLs and capabilities in the 
> same system? I suspect the answer is yes. If so, 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". For the discussion at hand, UNIX isn't the
goal, but UNIX certainly does seem to solve this problem well.