![]() | |||||||||||||
Messages in this thread |
* Andy Lutomirski (luto@myrealbox.com) wrote: > Chris Wright wrote: > > This does change the current notion of layering. I see your point though, > > likening it to say reading inode and finding S_ISUID bit. > > On the other hand, no one would put reading of a SELinux security label > here. But we already have fields in binprm specifically for commoncap. I > have no strong preference. Yes, I stopped short of that argument only because capabilities fall into a bit more of a gray zone than other modules. But I do prefer leaving it in the module. > >>The reason I killed the old algorithm is because it's scary (in the sense > >>of being complicated and subtle for no good reason) and because I don't see > >>the point of inheritable caps. I doubt anything uses them currently on a > >>vanilla kernel because they don't _do_ anything. So I killed them. > > > > This does break all those caps aware apps (yeah, tongue-in-cheek ;-) > > that actually have the idea to widen the effective set, yet limit the > > inheriable set. Seriously, I don't know how much this matters. > > Yah, they're broken anyway right now if that's what they're doing. On Linux they are. On IRIX they aren't. This is part of the issue as I see it. > The reason I didn't go for something like your approach (other than not > thinking of it) was that, as long as we're changing the semantics, we might > as well make them as clean as possible. I also didn't mind ripping out > lots of old code :). If the inheritable mask stays, then programs need to > be audited for what happens if they are run with different inheritable > masks. I'd rather just eliminate that complication and the corresponding > blob of commoncap code. Obviously my patch fails a lot of your tests as a > result. Actually the only glaring difference (aside from the uid/suid and non-root execs nonroot-yet-diff-id-setuid-app issue I mentioned earlier) is in something like "=ep cap_setpcap-ep cap_ipc_lock+i" IIRC. I have the feeling we both are after the same thing, which is introducing the ability to keep some caps through exec and still being able to sleep at night w/ confidence that there isn't some subtle new hole lurking. This is why I aimed to change as little code as possible. > So do we arm-wrestle over whose implementation wins? :) I'd say mine wins > on readability (not your fault -- the old code was pretty bad to begin > with) and some simplicity, but yours has the benefit of being less intrusive. Hehe, arm wrestling could be entertaining ;-) I'm in favor of the most conservative change, which I feel is in my patch. But I'm game to continue to pick on each. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/ | ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||