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

> * Andy Lutomirski (luto@stanford.edu) 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
result.

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.

--Andy
-
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 14:03    [from the cache]
©2003-2011 Jasper Spaans