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/