[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Capabilities

    On Fri, 11 Feb 2000, Theodore Y. Ts'o wrote:

    > The "allowed" capability bit set is the set of capabilities which the
    > program as allowed to *inherit* from the previously exec'ed image. This
    > means that by default, once you have this capability installed, setuid
    > inheritance doesn't work anymore by default!
    > If you install a normal program, both capability bitsets are NULL, which
    > means that if that program is run by a "root" shell, it doesn't inherit
    > any privileges from the privileged shell program. This is actually a

    I see real-world use of capabilities evolving in 3 stages

    1) Processes voluntarily dropping capabilities. This is the stage we are
    at now, and things like "bind" and "xntpd" will benefit from this. People
    doing this work have hit the major stumbing block that kicked off this
    thread (cannot drop uid==0 after dropping capabilities). I've sent Linus
    the fixing patch.

    2) Filesystem support goes in, but typical usage will be to just use the
    "forced" support, to keep traditional UNIX privilege inheritance but run
    suid root program with finer grained privilege. Note that stage 2) is by
    no means a configuration/maintenance problem

    3) The "allowed" filesystem set may or may not see usage. As mentioned,
    using the "allowed" sets is a setup/maintenance pain.

    The key point of this three stage plan is that at stage 2), you are
    reaping benefits from filesystem capabilities without the hassle of
    binaries not inheriting privilege in the traditional UNIX way


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