On Sun, 3 Nov 2002, Olaf Dietsche wrote:
> Linus Torvalds <torvalds@transmeta.com> 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?
I don't understand the question.
Let's say that you have a binary like /usr/bin/sendmail, and you want to
give it a certain set of capabilities (ie you want to _avoid_ making it
suid root - you only want to give it the specific capability of being able
to chown files to others and whatever else it is sendmail really wants to
do).
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).
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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:27 EST