[cap-talk] More Heresey: ACLs not inherently bad
kpreid at mac.com
Sat Sep 20 05:37:37 CDT 2008
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
>>> SCM program has write access to the tree? I don't think this
>>> 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
> On what basis does SCM gain access to that capability which Bob does
> 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; 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
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
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.
 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/>
More information about the cap-talk