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

[Jonathan S. Shapiro]

On Sun, 2008-09-14 at 16:25 -0700, Mark Miller wrote:
> On Sun, Sep 14, 2008 at 2:30 PM, Jonathan S. Shapiro
> <shap at eros-os.com> wrote:
>         
>         But another large issue is the simple system call overhead 
> 
> I'll address efficiency concerns after we better understand the other
> requirements and whether Horton can meet them.

Forgive me -- this is not directed at you personally -- but I don't
think that would be productive from my perspective. I've made several
attempts at stating the sharing requirements over the last two years.
While I have gotten back many individual helpful comments, my overall
summary of the reactions is that (a) there are multiple incompatible,
unrealistic and untested solutions proposed whose advocates are prepared
to bang on tables, and (b) there are several people who want to argue
that the requirements statement is wrong and therefore <insert solution
here> should be preferred.

On purely technical grounds I may even agree with many of the responses.
The problem, in the end, is that I need a survivable system *now*, and I
don't have time to re-engineer every application on the planet from the
ground up.

So the question isn't whether ACLs are good or bad. They serve a purpose
that people here want to deny (the graph sharing problem). There may
indeed be technically better ways to serve that purposes. It doesn't
matter.

The question that interests me at the moment is how to render a system
already built on ACLs survivable by applying capability intuitions to it
*without* ripping out the API that applications already expect. Like it
or not, that means that I'm committed to ACLs in this thought experiment
(though perhaps only in hybrid form).

Given the history of exchanges, this may not be the right forum for that
discussion.
 
>         and the fact
>         that no proposed Horton protocol is recoverable in the right
>         ways when
>         transitive grants across parties occur, which is part of the
>         problem in
>         my previously identified scenario.
> 
> I have to admit I've only lightly been skimming this thread. Could you
> restate, or point back at a self contained explanation, of what you
> consider the right ways to be to recover after transitive grants have
> occurred? Can you state the requirements abstractly enough to
> potentially admit multiple solutions?

Summary:

  1. Revocation of capabilities must be possible on a per-principal
     basis.

  2. Revocation of capabilities must not depend on the path by which
     they arrived in my hands.

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 see no reason to believe that the
>         presence or absence of memory accounting impacts the recovery
>         problem
>         one way or the other.
>         
>  
> Other than memory accounting and system call overhead, are any of the
> other issues (like recoverability requirements) in any way specific to
> OS-based caps rather than, say, language-based or crypto-based caps?

Only in the sense that replicating ACLs with Caps isn't an advantage,
which probably means that Horton isn't the right approach.


shap