Messages in this thread | | | Subject | Re: Capabilities | From | tytso@valinux ... | Date | Fri, 11 Feb 2000 05:17:40 -0800 |
| |
Date: Fri, 11 Feb 2000 13:08:39 +0000 (GMT) From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
On Thu, 10 Feb 2000 willy@thepuffingroup.com wrote:
> it though. One thing the capabilities people could help us with is by > saying whether they are willing to restrict themselves to 32 capabilities > for ever or whether they think they will need more (and if so, how many? > Is there a realistic upper bound?).
In 2.3 I believe we are currently using 28/32.
We are just starting to see some real-world usage of capabilities, in the form of restricting the capabilities certain daemons are running with. As capabilities are used more, a few ommissions will be detected and I think we will overrun 32 bits.
Since filesystem data structures are, shall we say, tricky to change after the fact, PLEASE budget 64 bits. 64 bits should suffice relatively long term. Do people concur?
Well, there's a trade off here. If you could have 32 bits basically almost right away, and more would take longer, which would you choose? Also, keep in mind that more bits is not necessarily good. There is a *huge* complexity cost in maintaining capabilities. People have enough trouble keeping track of the 12 bits of permissions on a per file basis. This adds one or two orders of magnitude of more bits for every executable.
However, my knowledge of human nature being what it is, I agree with you that unless very strong measures are taken to control the virtual explosion of new capabilities people will want to add, we will need more bits. So I'd suggest either putting a hard limit on 32 bits, or budgeting 128 or 256 bits, since bits are relatively cheap once you exceed 32.
People who are interested developing capability source should seriously think about ways to control the complexity, though. If the user-mode management tools aren't good enough, capabilities will be a diaster, and their use could actualy decrease the overall security on a system.
- Ted
- 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/
| |