> > Hi!
> [snip stickybit+immutable desc.]
> > Too bad this is not option: immutable bit is ext2 specific. These are
> > not only nfs problems you would have to face: there are also umsdos
> > and tar and coda and ... problems.
> I know that this scheme breaks over nfs and coda, but it can be
> made to work just fine with cp, tar, et. al.
>
> Now, I assume that our goal in putting caps in the elf headers is
> to give us true capabilities support for elf binaries. At least, that is
> _my_ goal. If that is _your_ goal as well, then here I will prove that
> setuid0 will not work at all, even on a local ext2 fs. It has to do
> with
My goal is not to provide true capabilities. My goal is to provide
usefull extension to elf headers in such way that it can be used now.
> This means that, not only is the permitted set important for a
> file (which works fine under setuid0), but also important is the
> inheritable set; i.e., setting the inheritable set should be a
> priviledged
I do not see why setting inheritable set should be privileged.
In traditional unix, every utility has inheritable set set to FULL by
default. I do not think it is good idea to change that.
> Let's consider the chown(1) program, for a nice, concrete example.
>
> - CAP_CHOWN is the capability required for changing the owner of a file.
>
> - The CAP_CHOWN cap should be flagged in the inheritable set of the chown
> binary, and if it's also flagged in the inheritable set of the parent
> process, chown(1) should be capable of setting the file owner.
I just think that CAP_CHOWN should be set in nearly any utility,
including utilities users compile themselves.
> - With the stickable solution, the file is marked +t and immutable, which
> is a priviledged operation but otherwise harmless; with setuid0, you have
> to make chown(1) setuid root! If you _don't_ require setuid0 on binaries
> with an inheritable set, you open yourself to normal users being able to
> create binaries that can inherit all the caps from it's parent
> process.
...which is completely ok in my eyes.
> > PS: Sorry, immutable bit just is not correctly supported these days.
>
> What do you mean by this, btw?
I mean that utilities like tar _do not support_ bits like immutable,
today. So you could really add new flag 'capability enhanced' instead
of overriding immutable.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/