[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: caps in elf headers: use the sticky bit!

    > > Hi!
    > [snip stickybit+immutable desc.]
    > > Too bad this is not option: immutable bit is ext2 specific. These are
    > > not only nfs problems you would have to face: there are also umsdos
    > > and tar and coda and ... problems.
    > I know that this scheme breaks over nfs and coda, but it can be
    > made to work just fine with cp, tar, et. al.
    > Now, I assume that our goal in putting caps in the elf headers is
    > to give us true capabilities support for elf binaries. At least, that is
    > _my_ goal. If that is _your_ goal as well, then here I will prove that
    > setuid0 will not work at all, even on a local ext2 fs. It has to do
    > with

    My goal is not to provide true capabilities. My goal is to provide
    usefull extension to elf headers in such way that it can be used now.

    > This means that, not only is the permitted set important for a
    > file (which works fine under setuid0), but also important is the
    > inheritable set; i.e., setting the inheritable set should be a
    > priviledged

    I do not see why setting inheritable set should be privileged.

    In traditional unix, every utility has inheritable set set to FULL by
    default. I do not think it is good idea to change that.

    > Let's consider the chown(1) program, for a nice, concrete example.
    > - CAP_CHOWN is the capability required for changing the owner of a file.
    > - The CAP_CHOWN cap should be flagged in the inheritable set of the chown
    > binary, and if it's also flagged in the inheritable set of the parent
    > process, chown(1) should be capable of setting the file owner.

    I just think that CAP_CHOWN should be set in nearly any utility,
    including utilities users compile themselves.

    > - With the stickable solution, the file is marked +t and immutable, which
    > is a priviledged operation but otherwise harmless; with setuid0, you have
    > to make chown(1) setuid root! If you _don't_ require setuid0 on binaries
    > with an inheritable set, you open yourself to normal users being able to
    > create binaries that can inherit all the caps from it's parent
    > process.

    ...which is completely ok in my eyes.

    > > PS: Sorry, immutable bit just is not correctly supported these days.
    > What do you mean by this, btw?

    I mean that utilities like tar _do not support_ bits like immutable,
    today. So you could really add new flag 'capability enhanced' instead
    of overriding immutable.
    The best software in life is free (not shareware)! Pavel
    GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

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