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

[Jonathan S. Shapiro]

On Thu, 2008-09-18 at 22:15 +0000, Baldur Johannsson wrote:
> One idea to solve the original problem statement is to use nodes
> (similar to gnu/linux
>  fs3 i-nodes) that each have an list (which could just contain one
> item) of sealed capabilities
> to the "real" object in question...

Unless the lookup mechanism is implemented in-kernel, this will fail the
efficiency requirement. If the lookup mechanism *is* implemented in
kernel, then you seem to be describing ACLs.


> 18. september 2008 Jonathan S. Shapiro <shap at eros-os.com>:
> > That is: in the absence of persistence we are going to end up with a
> > layer where there is something that amounts to a shared global file name
> > space (or equivalently, a shared global object space) and we will then
> > face challenges with both re-establishment of rights on restart and
> > enforcement of those rights.
> >
> This sounds exactly like the stuff that requires the pseudo-user
> account hack used
> for apache and the use of setuid. (That is, SCM has its own user
> account and when invoked runs as that user)

You seem to be presuming an ACL system here. The challenge was to show
how to do all of it in a capability system.

> But there is another solution to this proplem. It requires that the
> fileserver (or the object persistence keeper) allow triggers that
> start and hand over access to the SCM server to that object subtree
> (if we have hierarchical namespace) when something tries to access
> that object subtree for the first time and the SCM server (or what
> ever it is that is started by the trigger) isnt already running.

I'm suspicious that the propagation of authority in this scheme will get
the wrong answer, but I think this may be worth going into further. The
challenge is going to be showing that the file server has the right to
start some second server (in this case SCM) that runs using resource not
owned by or accessible to the file server.


shap