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

    > > 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.
    Pavel
    --
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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