[cap-talk] Petname definition: MinorCtkrFs, are these petnames?
Rob Meijer
capibara at xs4all.nl
Fri Jan 30 04:54:02 EST 2009
On Thu, January 29, 2009 15:50, Toby Murray wrote:
> On Thu, 2009-01-29 at 15:00 +0100, Rob Meijer wrote:
>> That would be:
>>
>> find <ATTENUATION DIRECTORY NODE SPARSECAP> -type f -exec attr -g attn
>> {}
>> \; | grep <ATTENUATED SPARSECAP>
>>
>> That would return something like:
>>
>> Attribute "attn" had a 57 byte value for <ATTENUATION DIRECTORY NODE
>> SPARSECAP>/<PETNAME>: <ATTENUATED SPARSECAP>
>>
>
> I forgot to add: Does the system prevent you from creating more than one
> petname (within a particular petnamespace) for the same capability?
>
> Cheers
>
> Toby
Creating a node (mknod) in the <ATTENUATION DIRECTORY NODE SPARSECAP>
namespace creates both the new petname and the new capability.
It is thus not possible to create more than one petname for the same
capability if seen from that level of abstraction. But all capabilities
within the <ATTENUATION DIRECTORY NODE SPARSECAP> namespace are in fact
capabilities for attenuated proxied access to the exact same capability.
That is, a process Alice with an unattenuated cap to some DirNode can use
that cap to get the <ATTENUATION DIRECTORY NODE SPARSECAP> of that DirNode
object. Within this attenuation directory, Alice could create two new
nodes, one named 'ForBob' and one named 'ForCarol'. Alice could use chmod
to pre-revoke some privileges and getxattr to get the capabilities that it
could delegate to Bob and Carrol. After delegation both Bob and Carol
would have a capability giving them attenuated access to the DirNode, but
both attenuations could be different in their privileges and could be
revoked by Alice using the petnames independently.
Rob
More information about the cap-talk
mailing list