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