Messages in this thread | | | Date | Sat, 12 Feb 2000 15:45:09 +0100 | Subject | Re: Capabilities | From | (Grendel) |
| |
* 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 [unhandled content-type:application/pgp-signature] | |