> > 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
> 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
-- 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 email@example.com Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:21 EST