Messages in this thread | | | Date | Fri, 11 Feb 2000 17:09:44 +0100 | From | Pavel Machek <> | Subject | Re: Capabilities |
| |
Hi!
> > 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.
Well, 32 will be almost certainly exceeded: we are using 28 NOW. But -- do we really need two different capability lists for each executable? If not, we could have 64bits NOW (and that should be good enough).
Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
- 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/
| |