lkml.org 
[lkml]   [2000]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Capabilities
From
* 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]
\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans