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

[Baldur Johannsson]

> In my experience, there are three problems with ACL systems:
>
>  1.  The first I have already raised, which is the absence of explicit
>      designation. This is straightforward to repair in the way that
>      I suggested in the previous "Heresy" thread.
>
As  it was pointed out in that thread it is pretty annoying for
programmers to have to
specify Principal in *every* subroutine call.
>
>  2.  The second is not really an ACL issue, but it is a nearly
>      universal failure of ACL systems: identity is not preserved
>      in the face of distribution. What I really mean here is that
>      NSF is a complete balls-up mistake. This type of thing can
>      be resolved by cryptographic identities, and the Factotum work
>      in Plan 9 is a good example.
>
A moot point indeed.
>
>  3.  ACLs are not readily subdivisible. That is: it is very difficult
>      to transfer a subset of the authority represented by a Principal.
>      But I claim that this is also true of capability systems.
>
Can you please show me how I can wrap an access/authority into an
revocable and filtering forwarder?
And do so transparently to the access/authority receiving party?
>
> It is the third point that I want to focus on, because this is the area
> where we in the capability community complain most heavily about ACL
> systems. On reflection, I want to suggest that this problem is actually
> *worse* in capability systems.
>
> The main source of authority proliferation in ACL systems is through
> propagation name spaces. I argue that the *real* problem in ACL systems
> is not that principal IDs fail. The real problem lies in the face that
> namespace capabilities propagate across fork/exec in such systems by
> default, and in the fact that for the most part access to these
> namespaces cannot be mediated.
>
implicit by default == confusing situations ("where did that program
get the authority to write to the passwd/bookkeeping file!?!" ;-))
>
> *Given* that namespaces propagate by default, principal id's serve a
> useful purpose: they provide some degree of filtering on the damage. In
> a pure capability model, when a namespace is propagated,
>
When are such namespaces propagated in capability based systems?
>
> no  corresponding means of filtering is present. In consequence, propagation
> of namespace capabilities is even *more* damaging in capability systems
> than in other systems.
>
> From a usability perspective, the best mechanism we have come up with
> for bulk propagation and protection of authorities has been the power
> box. Observe that the protection of the power box derives entirely from
> its ability to act as a filter. The power box itself operates with the
> full authority of its user.
>
hmm? I thought an power box was simply an selector and an membrane that
followed the policy given by the user. Often the policy being defined
dynamically
by powerbox<->user interactions.

Cheers.