[lkml]   [2004]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] scaled-back caps, take 4
* Andy Lutomirski ( 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.

Linux Security Modules
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.059 / U:5.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site