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

[Kevin Reid]

On Sep 19, 2008, at 12:55, Jonathan S. Shapiro wrote:

> On Fri, 2008-09-19 at 15:54 +0000, Karp, Alan H wrote:
>> Shap wrote:
>>> However, I think your proposal extends to this fine, with only one
>>> challenge: how to ensure in a non-persistent cap system that only  
>>> the
>>> SCM program has write access to the tree? I don't think this  
>>> bootstraps
>>> without something ACL-like.
>>>
>> Sorry to be dense, but I don't see why the persistence of the  
>> permission state of the SCM is special?
>
> System restarts. Bob goes to check something in to the SCM tree. Bob
> kicks off a copy of the SCM agent. SCM agent needs access to the tree
> that Bob does not have.  This access must be granted by some  
> capability.
>
> On what basis does SCM gain access to that capability which Bob does  
> not
> have?
>
> Offhand, I cannot think of a scheme that is not identity based.

I agree with those who have said that this seems to be entirely  
orthogonal to the rest of your problem. That said, here's my solution:

I assume that while the system under consideration is not orthogonally  
persistent, it has a file system. That file system is itself  
persistent, and the SCM tree is a thing in the file system; therefore,  
store the authorization in the file system, as so:

Bob's access to the SCM tree consists of an item (cap) in his  
directory. That item is basically a *closure*; it contains references  
to the raw SCM tree and to the SCM agent program. Bob has an "execute  
only" cap[1]; the only important thing Bob can do with it is invoke  
it, which "kicks off a copy of the SCM agent", granting it access to  
the closed-over raw SCM tree.

Note that we're not letting orthogonal persistence creep in: there is  
no *process* stuffed into the filesystem, just a trivial instruction  
to invoke one, which in a non-capability system could just be a shell  
script or some such.

(In particular, the closest Unix analogue to this is a setuid program;  
the setuid bit and file owner together constitute the closed-over  
authority.)


The key idea here is: Even if the system is not fully persistent, the  
file system is. Therefore, make the file system capable of storing  
nontrivial authorities.

I believe this is generally applicable to the problem of recording  
installation endowments for applications, as well: in this particular  
case we can say we're doing a micro-installation of the SCM agent for  
one particular SCM tree.




[1] Rather than presenting the SCM as a sort of 'executable', another  
reasonable possibility is to present it as a subdirectory; in which  
case this closure-in-the-filesystem is like a Unix mount point plus  
userspace filesystem (but persistent).

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>