Messages in this thread | | | Subject | Re: updated proposal for cap in elf | From | (Eric W. Biederman) | Date | 17 Apr 1999 13:22:53 -0500 |
| |
>>>>> "DP" == David L Parsley (lkml account) <kparse@salem.k12.va.us> 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.
THE STICKY BIT IS ALL YOU NEED.
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.
Eric
----- P.S. 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |