Messages in this thread | | | Date | Fri, 11 Feb 2000 13:59:43 +0000 (GMT) | From | Chris Evans <> | Subject | Re: Capabilities |
| |
On Fri, 11 Feb 2000, Theodore Y. Ts'o wrote:
> The "allowed" capability bit set is the set of capabilities which the > program as allowed to *inherit* from the previously exec'ed image. This > means that by default, once you have this capability installed, setuid > inheritance doesn't work anymore by default! > > If you install a normal program, both capability bitsets are NULL, which > means that if that program is run by a "root" shell, it doesn't inherit > any privileges from the privileged shell program. This is actually a
I see real-world use of capabilities evolving in 3 stages
1) Processes voluntarily dropping capabilities. This is the stage we are at now, and things like "bind" and "xntpd" will benefit from this. People doing this work have hit the major stumbing block that kicked off this thread (cannot drop uid==0 after dropping capabilities). I've sent Linus the fixing patch.
2) Filesystem support goes in, but typical usage will be to just use the "forced" support, to keep traditional UNIX privilege inheritance but run suid root program with finer grained privilege. Note that stage 2) is by no means a configuration/maintenance problem
3) The "allowed" filesystem set may or may not see usage. As mentioned, using the "allowed" sets is a setup/maintenance pain.
The key point of this three stage plan is that at stage 2), you are reaping benefits from filesystem capabilities without the hassle of binaries not inheriting privilege in the traditional UNIX way
Cheers Chris
- 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/
| |