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

[Baldur Johannsson]

2008/9/13 Jonathan S. Shapiro <shap at eros-os.com>:
> Arrggh. Let me try this again.
>
> There exists a sharing problem that ACLS uniquely solve, and that
> appears to *require* the de facto separation of designation and
> authority. It is possible to solve this problem on top of a pure
> capability substrate, but only by implementing a filter whose net effect
> is to simulate the behavior of ACLS or something very close to them.
>
> 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.
>
> Note that because the graph itself is being modified, making
> replicates of the graph for each party is infeasible. This devolves
> to the distributed filesystem problem. The proof by example that it is
> possible to manage this problem was once called RFS. The existence
> proof that users will not tolerate the cost of such consistency is
> called NFS.
>
> Note further that the implementation of per-party access right
> distinctions cannot be achieved by capability-based permissions
> within the graph. If we downgrade some cap to prevent Alice from
> accessing a subgraph, all other users will also be downgraded because
> the structure is shared.
>
> So far as I can tell, the only workable method for solving this problem
> is mediation of all accesses to the graph in a per-client-user fashion.
> While this can be implemented by user-mode code on top of a capability
> substrate, it appears to me that this emulation constitutes, for all
> practical purposes, an access control list.
>
Hmm..

Wrapping the shared object graph in an membrane that has an
per-client-user mediator
is much handier as the changes to the access lists of those mediators
can be governed
by capabilities and all the usual patterns and so forth.

Which is exactly what has been the most annoying limitation of traditional ACLs:
Who as access to change the access control list of this object?
And who in turn have access to change that list and so forth infinitely.
Which hampers delegation and hench users just give everyone their
access to everything
they have access to. (I have seen this first hand)

ACLs are one possible policy mechanisms of many that can be
implemented on top of
capability and object-capability based substrate.
While other policy mechanisms cant easily be implemented on top of ACL
based substrate.

So implementing ACLs on top of an ocap substrate where other policy
mechanism can intermingle with them is probably better as it allows
for more flexibility. (And flexibility increases the utility of the
overall system and hence is more valuable)

Cheers
-Baldur