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

Mark Miller erights at gmail.com
Sun Sep 14 18:25:33 CDT 2008


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.


> 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?



> 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?

Actually, I just remembered another that you mentioned earlier in this
thread: legacy compatibility / retrofit effort. Each substrate will have its
own unique legacy with its own unique problems. Having spent more than a
year now on perhaps the worst case for an achievable language retrofit --
JavaScript -- I have learned not to underestimate the pervasive effect it
has on other design decisions. But, like efficiency, the road to clarity is
perhaps shortest when we first try to understand what would be right (like
recoverability requirements) in their absence.

-- 
  Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080914/11e843fe/attachment.html 


More information about the cap-talk mailing list