> I think something which causes most people to react negatively to this
> scheme is that they have huge issues wrt overloading the longstanding
> behavior of 'setuid root == runs with root privs'. I see why Albert wants
> to use the root +s bit to mark capabilities-using binaries; it will be easy
> to support w/existing file tools, etc. But still, u+s files owned by root
> are scary, for good reason -- perhaps we don't like the ramification that
> if this system is rebooted to another kernel, or its filesystems NFS
> mounted by a box that doesn't support capabilities, whatever. Scary, messy
> things will eventually happen in a scheme like that.
>
> So... who says the +s, capability-enabled binaries need to be +x ?
Hey! I like this!
> Trying to execute a setuid, non-executable binary on a machine that doesn't
> support capabilities should be meaningless and therefore harmless, no?
> (unless there some existing significance of u+s, u-x files, like +t on a
> file, whether POSIX enforced or simply convention.)
>
> if (is_noexec) {
> if(setuid){
> if(root_owned && cap_header) use_cap_header();
> else
> meaningless, EACCES or whatever as usual
> else
> normal no-capabilities setuid/nonsetuid, whatever
No.
Make it better. Do _NOT_ require -x on capability-enhanced files. User
has to choose. He may or may not set x on such files. It is _his_
choice. If that daemon has near-full set of capabilities, anyway, it
has good sense to make it u+x, u+s.
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- 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/