On Fri, 11 Feb 2000, Chris Evans 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.
[..]
> 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?
Yep, we agree on this. When I investigated extracting some of the
worst offenders from CAP_SYS_ADMIN, I had to create[0] another three
caps before I could even start to get my head around the CSA mess.
Andrew Morgan has usefully suggested that some operations should
require combinations of privs, which lets us avoid having far too
many, but most of those we have at the moment are way too general
purpose for us to use that idea usefully.
Realistically, I think 40 or 48 bits should be enough, but I wouldn't
like it to be my fault when the disk structures have to change again,
so 64 gets my vote anyway :-)
Matthew.
[0] Conceptually, you understand. It never quite got as far as
becoming a patch.
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:20 EST