Of course, you've completely busted up security. On my machine
there's a crypto-daemon that wants to mlock() some RAM. I have a little
setuid wrapper to give it mlock capability on 2.2.x, but I'm not about
to let it run with full root privs -- under 2.0.x (or whenever it can't
mlock()), it prints a detailed warning and lets the user decide whether
the risk is worth the convenience of not typing passwords constantly.
The whole point of capabilities is that you only trust a daemon with
some small set of powers -- promoting it to full root privs is downright
dangerous.
Requiring a setuid wrapper as I have now is pretty bogus.
Also, explain how I do each of the following in your scheme:
1. Make an executable that runs with UID 0 but no capabilities.
2. Make an executable that runs with exec'rs UID and capabilities.
3. Make an executable that runs with UID 0 and capabilities.
with real capabilities in the fs:
1. owner 0, setuid, no capabilities are set
2. owner anyone, no setuid, capabilities are set
3. owner 0, setuid, capabilities are set.
--Sumner
-
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/