[lkml]   [1999]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: inheritable set [was Re: caps in elf headers: use the sticky bit!]
       Date: Sat, 17 Apr 1999 18:37:02 -0400 (EDT)
    From: Alexander Viro <>

    > You can do full POSIX capabilities and still be Unix; and the way you
    > solve this problem using model outlined by the POSIX capabilities draft
    > is that /usr/ucb/Mail would no longer be setuid root, so "more" would not
    > be running with uid 0, and neither would the shell executing from more.
    > /usr/ucb/Mail would instead have a capability which allowed it to
    > override filesystem discretionary access controls, or whatever other

    ... i.e. would be able to modify files that don't belong to its UID. E.g.
    /etc/passwd. Q.E.D.

    No, because "more" wouldn't have any capabilities in its "inheritable"
    set, so it would NOT inherit any capabilities which its parents had.
    This is why it's important for programs to by default have a null
    inheritable set, and to only inherit capabilities if they have an
    explicitly set of privileges which they are allowed to inherit. This is
    an integral part of the POSIX capabilities model.

    The problem here is that some folks either don't understand the full
    POSIX capaibility model, or keep trying to leave parts of it out in the
    hopes of simplifying things. The reality is that you really do need to
    implement the full POSIX capability model for things to make sense.

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.045 / U:169.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site