* Jesse Pollard said:
> >
> >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?
>
> Definetly want more than 32. I'd like to (potentialy) be able to control
> every system call through a capablity. I'm also a strong fan of MLS
> systems, it lets my paranoid side out when protecting systems:).
>
> I'd suggest using an index reference to a table containing multiple capability
> lists. The set of usable capability lists is limited. Many inodes, but the
> number of uniqe capability lists would be rather low (20-30 most likely).
> Using a reference:
[snip]
In a private mail to someone I have came up with a similar system for
capabilities using an indexed array, but constructed in a bit different way.
Below is a part of the mail that describes my idea. Maybe it makes a bit
sense to implement it that way?
-----------------
We define capability bits as an array of, up to, 256 entries. As the
capabilities are stored per-process, we have to preserve space and thus
limit the actual number of array slots to some necessary count. Now, the
individual capability is assigned a 32-bit value that looks like this:
bit(s) meaning
------------------------
31-8 a bitmask that uniquely identifies the capability
7-0 array slot 'selector'
This gives us a potential of max 24*256 capabilities (assuming that the
array is that of 32-bit words, I chose a common value for all the
platforms). In every slot 8 bits are "wasted" - they can be used by the code
to further tune the access rights to given _capability_ or used for any
other purpose that comes into mind. Such defined capabilities give us 256
potential "classes" of capabilities. For example, selectors (classess) 0 -
16 are the kernel-specific capabilities, other classes left for imagination
and registration. Kernel uses a mask for the selector part of capability, so
that bounds checking is performed - the arrays are as large as it is needed.
------------------
This doesn't cover filesystem capabilities storage, but I guess the
"resource inode" approach would be the best for this kind of implementation.
marek
-
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:22 EST