[lkml]   [1999]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Problem with Linux capabilities support
Pavel Machek wrote:
> > The problem is that this obliterates the previous capabilities
> > set. Once scap has started running, it no longer knows which
> > capabilites the user already had active. At the moment I get
> > around this by taking the capability set from the parent and
> > working from that. But that is bad.
> fork() and then look at _your_ parent.

You mean have the original program non-setuid? Either way, fork()
is going to get exactly the same capabilities as the parent, so
I don't see how this is going to help.

> > The second problem is that if scap is run setuid, at some stage
> > it has to switch back to the previous uid, at which stage all
> > the capabilites are cleared and your work is undone. I know that
> what about two programs, scap0 and scap. scap0 is setuid. scap execs
> scap0, scap0 looks at its capabilities, and raises them as needed,
> then scap0 dies...

Would work, if programs could change other programs' capabilities,
which they can't, without a kernel patch (which I was trying to
avoid). CAP_SETPCAP is disabled for everyone from init down.

> > The first thing that popped into my head was to define a
> > CAP_ENLIGHTEND which can be set but not inherited. When set
> > it would prevent uid changes from modifying the capabilities
> > sets. When user space is ready, you can simply #define it to
> > zero.
> Please don't do this. There are 4 bits left, and I need them :-).

Only 4? I was under the impression there were 16 left (though this
is 2.2. Maybe more are used in 2.3.

Do you have a better solution? I think its silly to expect every
program to be made capabilities aware when a few simple changes
will make you at least be able to run a mixed setup safely.


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:55    [W:0.041 / U:4.052 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site