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/