Messages in this thread | | | Date | Wed, 14 Apr 1999 16:03:25 +0200 | From | Pavel Machek <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
Hi!
> > 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/
| |