Messages in this thread | | | Date | Mon, 20 Dec 1999 14:11:48 +1100 | From | Martijn van Oosterhout <> | Subject | Re: [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.
Martijn
- 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/
| |