[cap-talk] Capabilities vs. identity/acl - the rub, rub, rub
Stiegler, Marc D
marc.d.stiegler at hp.com
Wed Nov 22 17:29:31 CST 2006
> and of course proxies can be auto restarted. I believe the
> root of the issue is that if you want to nail down where an
> access is coming from on an identity/acl based system, you can:
> 1. Look at the object, it's permissions for owner, group, world.
This is no different from what you can do with the design we have for
the CapWiki: you can see all the caps you have created on your
resources, who you gave them to (as long as you don't lie to yourself
when you're creating the cap, describing who you're sending it to :-),
and what direct permissions those caps embody.
> 2. You can look up the groups and come up with a set of
> identities that can access the object.
Performed by the same machinery inside the CapWiki design as the
machinery for solving #1, you just list the names of the people you're
emailing to, or, if there is a location to which you can send a cap for
being used by a group of people (a feature of DonutLab), it works the
> 3. You can look for any process with any of those identities.
> Any access must come from one of those processes.
This is a surprising thing to claim that anyone can do in an acl system.
Are you assuming that everyone is running as sys admin? Certainly, on
Windows only the sys admin can see all the processes running for all the
identities. Is Linux more broken than Windows on this matter, so
everyone can see all the processes I run?
Regardless, the functionality of this is supported to the same extent
in the CapWiki design: when an access comes in, it must come from one of
those caps. So we track the cap, not the process, but the info one can
derive is the same, namely, who made the direct access, i.e., who to
hold accountable, even if the cap/process is being used as part of a
To sum up, the list of feature you seek is supported to the same extent
with caps as with acls.
More information about the cap-talk