Messages in this thread | | | Date | Wed, 22 Apr 1998 15:39:30 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Date: Sun, 19 Apr 1998 14:22:08 -0700 From: Andrew Morgan <morgan@transmeta.com>
provide backwards compatability for legacy setuid applications. For all the reasons that the capability model is a good one, making use of 'fE' is strongly discouraged. The obvious alternative to a single bit of 'fE' capability is to have a complete multi-bit 'fE' set -- indicating which of the new process' permitted capabilities should raised in the effective set. fE is defined to be one bit to strongly discourage this "lack of programming" practice.
The tradeoff is that "lack of programming" allows people to start using capabilities in systems without needing to modify the programs to explicitly make system calls calls to raise their capability level. You can simply set a program like inetd to have the CAP_BSD_RESERVED_PORT_REALLY_BAD_IDEA capability, and you're done.
In the long run, it's better to explicitly make the programs explicitly ask for capabilities, if for no other reason than to simplify the configuration/management problem of having to manage all of the capability bitfields on all of the executables on your system. But there is the short-term implementation issue.
Given that 2.2 won't have the capability support in the filesystem (sorry, I'll work on getting that into the ext2 filesystem during 2.3, I promise!), this may be less of an issue, since we're going to need programming changes in the user-side tools before we can really take advantage of capabilities for real.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |