[lkml]   [2004]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] scaled-back caps, take 4
Chris Wright wrote:

> * Andy Lutomirski ( wrote:
>>Chris Wright wrote:
>>>Thus far we've kept all this stuff out of core. I believe we should
>>>keep it that way. This could easily be left in bprm_set().
>>True. But as long as linux_binprm has fields for this stuff, intuitively
>>it should always be filled in (i.e. not just in commoncap). That way we
>>can say that commoncap doesn't get special treatment :)
>>Also, this seems like the right place to check for VFS caps. This way we can.
> 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.

>>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.

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

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.

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.066 / U:6.612 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site