On Mon, 17 May 1999, Theodore Y. Ts'o wrote:
> My big question with Pavel's patches is that if you're just dropping
> privileges, why not just do it programmatically in the program?  
a) legacy support
b) c++ and others sometimes has stuff run before main; constructors
c) provibility
> take care.  So the programmer is in the best position of decided which
> capabilities/privileges it needs, and should simply have the opportunity
> to drop everything it doesn't need.
Yes I have to agree in the long run the need for the binary headers will
decrease and decrease.
after something like ext3 with caps support is made.
when bash has new builtins to manipulate its runnings caps.
when someone runs swig on libcap for perl and python.
When all the daemons have been cap-enhanced, etc.
When all the useradmin tools have been cap-enhanced.

Right now I think getting prepare_binprm working in a sane cap-enhanced
matter is the biggest current issue. After that then libcap which looks
really good IMHO. Then mechanisms like binary cap headers and vfs support.
In the long run vfs support is critical. 
binary cap support is not long time critical IMHO.
Linus should be weary of the binary cap headers; he should weigh todays
usefulness with the chance that it might become tommorows baggage.

I will continue to have binary cap headers among my patches but I am not
advocating it be placed in the kernel until after the stuff to support
libcap1.92, the prepare_binprm etc cleanups have been made, and
setresuid_c debated and other stuff.  


--
Any caps I mention are *derived* from a withdrawn draft posix document.
See http://www.millenniumproductsllc.com/sjp/ for more info.


-
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/