> > > 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
suid scheme may be ugly and it may take away lot of flexibility
away. However it does not change current semantics, it is reasonably
clean to code, and it will be usefull for many purposes, anyway.
Pavel
PS: Take a look at my previous PS :-).
> > 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.
-- 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/