Messages in this thread | | | Date | Wed, 12 May 2004 18:55:28 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 0/2] capabilities |
| |
Andy Lutomirski <luto@myrealbox.com> wrote: > > > > > What if there are existing applications which are deliberately or > > inadvertently relying upon the current behaviour? That seems unlikely, but > > the consequences are gruesome. > > Like something that turns KEEPCAPS on then setuid()s then executes an > untrusted program?
Or if it simply has caps and then does exec.
> > If I'm right in this concern, the fixed behaviour should be opt-in. That > > could be via a new prctl() thingy but I think it would be better to do it > > via a kernel boot parameter. Because long-term we should have the fixed > > semantics and we should not be making people change userspace for some > > transient 2.6-only kernel behaviour. > > The prctl would defeat the purpose (imagine if bash forgot the prctl -- > then the whole thing is pointless).
yup, lots of apps would need to be changed to interface with something which won't be present in 2.8 kernels.
> I'll cook up the boot parameter in > the next couple days (probably with a config option and some kind of > warning that the old behavior is deprecated).
I wouldn't bother with a config option.
> Is it a problem if I make > the changes to init's state unconditional? (I still don't see why > CAP_SETPCAP is dangerous for root to have...)
I'd be more comfortable (ie: comfort level non-zero) if there was zero behaviour change if the boot option isn't enabled.
> The only concern is that some new code relies on the new inheritable > semantics. That shouldn't be so bad, though, since that's just an extra > precaution (if there are insecure setuid binaries around, you already > have problems).
Yes, we can live with that. The price of prior sins. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |