Re: Filesystem Capabilities in 2.6?

[Alan Cox]

On Sun, 2002-11-03 at 02:03, Linus Torvalds wrote:
> So I'd suggest _not_ attaching that capability to the sendmail binary
> itself, or to any inode number of that binary. A binary is a binary is a
> binary - it's just the data. Instead, I'd attach the information to the
> directory entry, either directly (ie the directory entry really has an
> extra field that lists the capabilities) or indirectly (ie the directory
> entry is really just an "extended symlink" that contains not just the path
> to the binary, but also the capabilities associated with it).

So what are the semantics for writing to the file. If I modify a setuid
(or setpartlysetuid) type file then I wan't the setuidness revoked as
happens now. That is done for very good reason. Your system appears to
need a scan of the entire file system to find directory references to
this object, done atomically. 
 
> The reason I like directory entries as opposed to inodes is that if you
> work this way, you can actually give different people _different_
> capabilities for the same program.  You don't need to have two different
> installs, you can have one install and two different links to it.

I'll trade 500K of disk space for a working security model especially as
the case in question is not that common.

Alan