[lkml]   [2000]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Capabilities
    * 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:
    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.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 13:56    [W:0.020 / U:47.952 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site