> > I suspect that it would be cleaner to have capabilities be a name-space
> > issue rather than an inode issue. For example, the one thing I've always
> > wanted to do with symlinks is to have symlinks that can change the
> > privileges of the lookup - it's complex and maybe not a good idea, but
> > it's a more intriguing concept and works with shellscripts and other
> > systems where you can't add ELF notes..
> With binfmt_script the real executables are bash, perl, python, etc.
> With them I don't think any binary cap header restrictions should be used.
> I do think that new some shell builtin(s) might be nice.
> Also for perl and python, someone should use swig on the libcap.
>
> Anyway I disagree that any of it should go into 2.3.x until some other
> issues get worked out. Pavels and my patch are different in some of their
> details concerning binary cap headers. I'd like to see if we can resolve
> some of them. I also think that prepare_binprm and a few other things need
Well, if you expand fields to be 128bit and add your disinherite
fields at the end, there should be no problems with
compatibility. I.e. my patches will eat work with those parts of
headers they do understand - which is right thing to do.
Pavel
-- 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/