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

[Jonathan S. Shapiro]

On Wed, 2008-09-17 at 07:16 -0400, Kevin Reid wrote:
> On Sep 15, 2008, at 13:09, Jonathan S. Shapiro wrote:
> > While it is possible to build membrane systems that automate the
> > capability exchange protocols required to meet both requirements, the
> > only thing one has achieved in the end is to replicate ACL systems
> > inefficiently.
> 
> I don't see how any system could be both externally interpretable as  
> an ACL system, and not arguably an 'inefficient replication' of an ACL  
> system. I'm interested in solving this problem, but it seems to me  
> that these two requirements might be mutually contradictory.

Not contradictory at all. I'm pointing out that if the desired semantics
for a problem is ACL semantics, building a non-obvious, complicated,
slow implementation of ACLS with fairly nasty (and in principle
unresolved) storage accountability and reclamation problems doesn't seem
to provide any benefit merely because that implementation is constructed
on top of a capability substrate.

Capabilities are not good because they are capabilities. Capabilities
are good only to the extent that the provide solutions to problems that
ACLs can't solve. I think there are quite a lot of those problems lying
around, but implementing ACL semantics (such as it is) is clearly a
problem that ACL systems can solve just fine.

The use case I am looking at is one in which ACLs really do appear to
capture the right intuition, and in which separation of authority and
designation truly does appear to be a functional requirement.

I'm a bit frustrated because it seems that many people here are having
difficulty with the concept that the world does not consist entirely of
leaf objects, and that the capability community has not brought forward
a satisfactory solution to the any graph sharing scenario in which
different parties must have distinct access rights.

> Given your stated summary, the system which comes to mind is this:
> 
> Each principal holds references to the graph via a membrane specific  
> to it.

OK

> The membrane holds a table of nodes and access levels;

The graph structure is not static. How do we keep an arbitrarily large
number of membranes consistent in their view? You're going to need a
transaction system in the core system semantics, and you're therefore
going to run into trouble with storage availability and/or
accountability problems. This will trickle down into an unreliable
update semantic.

All of this is why I stated in an earlier note that we have a lot of
experience with in the file system world that coherent file systems are
too expensive and incoherent file systems are not robust. I'm suggesting
that any solution predicated on multiple membranes is likely to share
the same issues, because it is essentially the local special case of the
distributed filesystem problem.

>  when a  
> cap passes from the graph to the principal, that access level is  
> provided through a facet; in the other direction, the cap is unwrapped/ 
> converted to the 'base' state that lives in the graph.

OK. Now can you explain how, when one of the wrapped capabilities gets
passed from one user of the data set to the next, and the first user's
access is revoked while the second user still holds the descriptor, the
second user's access rights through the descriptor are preserved?

> Note that this system does not store a table of principals in any  
> nodes, and does not communicate any "principal IDs" to the nodes; as  
> such, it is arguably not an ACL system.

Umm. Actually, the system does do just that. The facet ID on the
membrane is the ACL ID, and the rule set used by the membrane for
permissions is the access control list. The fact that these are not
directly stored on the nodes is not semantically significant; it is
merely an accident of implementation.

The respects in which this is not an ACL system are:

  1. The rule set is not restricted to principal-based predicates
  2. The principal id (in the form of the membrane facet) is
     delegatable.

We're not exploiting the first issue here. I agree that the second point
is useful, which is part of why I think the "first class file system"
notion of Plan 9 was important, and also why I think that the "first
class name space" notion (i.e. that an initially empty namespace should
be nameable by a file descriptor) was an important missing element in
Plan 9. Dave Presotto concurred in hindsight, and allowed as how that
would have simplified a bunch of things.

> This meets your first summary requirement, as the membranes may be  
> individually controlled, and your second, as the membranes unwrap as  
> references return to the graph, so they do not stack.

Yes to both. But the solution requires that all interactions between
users proceed through the membrane mechanism. This precludes, for
example, my emailing a descriptor to another member of the working
group.

This may be a case where some form of external reference form is desired
for interchange purposes, but we still need a solution that works out
right under simple and direct capability transfer.

> Do you consider this a (replication of an) ACL system?

No, because of the problem that transfer must proceed through the
membrane to preserve ACL access semantics, and that is desired in this
case. However, I agree that it is something very close to an ACL system.
And to the extent that converges, my response will be "So if it's an ACL
system, why are we building it in this absurdly hard way?"

> Does it meet your original requirements?

Yes, but only because I took the direct transfer requirement for granted
and failed to state it explicitly.

> Given that you are interested in applying capability intuitions to an  
> ACL system, why do you care that a capability implementation (or  
> interpretation) of the system happens to mirror the ACL-system  
> structure closely?

Because a lot of existing apps have to work. And from my comments above,
it should be clear that I *don't* want this. I'm absolutely not
interested in using caps to build bad ACL systems. I'm interested in
supporting an existing, required, and in some cases legitemate
functional requirement that ACLs seem to satisfy.

shap