[lkml]   [2002]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Filesystem Capabilities in 2.6?
Linus Torvalds <> writes:

> On Sun, 3 Nov 2002, Olaf Dietsche wrote:
>> Linus Torvalds <> writes:
>> > - Make a new file type, and put just that information in the directory
>> > (so that it shows up in d_type on a readdir()). Put the real data in
>> > the file, ie make it largely look like an "extended symlink".
>> How would you go from a regular file to the new extended symlink?
> 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).

Now I understand. It's a combined symlink/capabilities pair. I thought
to have this extra direntry, containing capabilities only. But I
didn't get the connection between the binary and the cap direntry. You
go just the other way round from cap/symlink to the binary.

> 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 thought that's what the inheritable vs. permitted set is for.

Regards, Olaf.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [W:0.350 / U:0.464 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site