[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: caps in elf headers: use the sticky bit!

> > 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.
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.137 / U:2.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site