[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.023 / U:1.156 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site