[lkml]   [1999]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: updated proposal for cap in elf
    >>>>> "DP" == David L Parsley (lkml account) <> writes:

    DP> Hi all,
    DP> My thinking on this implementation has been very fluid over the last
    DP> several days; many have stimulated new thoughts for me, others have just
    DP> made excellent suggestions. So thanks to all of you.

    DP> I think Ted's idea of using a new extended attribute bit to mark a file as
    DP> capability-enabled is the best idea yet. The sticky bit idea was a bit
    DP> broken, requiring the kernel to honor a once-useless (and non-priviledged)
    DP> bit as now essentially all-powerful.

    DP> To fix this, we tied in the
    DP> immutable bit, but of course that means it can't be used for it's intended
    DP> purpose.

    You obviously misunderstood what I was suggesting.
    I was using the immutable bit 100% for it's intended purpose.

    People kept asking (the rather irrelevant question) what happens when
    I boot to an older kernel. So I outlined a user space solution which
    used the immutable bit. Since that problem is solvable that objection is
    no longer valid.


    Clearing the sticky bit when it is written to solves any problems
    (not involving a different kernel).

    I think the way to implement all of this is with 2 patches.
    1) Minmal support of capabilites in the VFS layer. (Which likely could go into the kernel)
    2) A forwarding filesystem that takes options to say which filesystems
    to really mount, and wraps the calls just enough so it works.

    Note. The code should be built with an eye to also support the
    standard system calls for setting filesystem capabilites when they
    become present in the kernel.


    For those who missed it the user space solution was:

    1) Before going to the old kernel set the immutable bit on every cap
    enhance executable.
    2) When returning from the old kernel clear the sticky bit where the
    immutable bit is not set.
    3) If you have the immutable bit set when running a capability
    enhanced kernel is a user space decision. (It could only help
    security however).

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