> Hi!
>
> > The problem is, to get good semantics, there are a lot of repercussions
> > which all need to be thought out. For instance, I now find that besides
> > needing to store the true owner of the file in the headers, we also need
> > to store the true value of the setuid bit, to determine whether the file
> > actually executes as the owner or not. (group info is _not_ needed)
>
> If you took a look at patch, you'd realize that this is already
> done. 2 lines of c ;-).
Ok, but say the perms on the file are
-rws------ root root, but in the elf headers 'parse' is listed as the
owner and non-setuid. Now I can't even run my own binary. Marking a
capability-enabled binary with a 'magic' uid is just ugly, and takes away
a lot of the flexibility of a true capability-enabled system. The sticky
bit solution gives us virtually _all_ the functionality of a cap-enabled
system. It's perfectly possible, too, that the above file could have
group rights for a group 'parse' is not a member of. Then others in that
group _could_ execute it, but not me! Making this scheme work the way it
should will make the hack much deeper and uglier.
The 'sticky bit' solution is just so attractive to me, because it works
97% exactly like real caps in the fs would, and already, for free, we have
this unused bit in the fs that can do everything we need. _IF_ we think
though it.
BTW, whoever said the sticky bit should be un-set on a write is perfectly
correct, that's the best way to do it. 'immutable' was a poor idea
on my part.
>
> Pavel
> PS: Patch actually does not change semantics of almost anything:
> Setuid root can do _anything_...
>
> ...which for example means it can volunteerily give up its
> rights. What capelf does is that instead of dropping it at beggining
> of main (which is doable _right now_), it drops them even sooner _AND_
> external program like lscap can verify that it is really going to drop
> privileges.
> --
> I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
> Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
>
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/