lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Capabilities
Matthew Kirkwood on Thu, Feb 10, 2000 at 08:13:42PM +0000: 
>On Thu, Feb 10, 2000 at 08:13:42PM +0000, Matthew Kirkwood wrote:
>> On Thu, 10 Feb 2000, Chris Evans wrote:
>> > We will have filesystem support soon.
>>
>> I see no evidence of that.
>
>We discussed this briefly last weekend. We _think_ we need to take the
>ext2 inode size up to 256 bytes anyway, which has its own associated
>problems. I'm not at all sure this will happen in time to get merged
>into even a later 2.4.
>
>Ted, one thing we didn't discuss was handling capabilities in much the
>same way as you proposed for ACLs --- a large number of programs want
>very similar capability sets. What do you think? If we did that, we
>could get away with using just 32 bits in the inode for capabilities.
>We should be very sure this is the right thing to do before doing
>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?).

For what its worth:
Not really (my opinion). I would like a set of system defined capabilities
that are enforced by the system. I would also like a set of user (the
security administrator) defined set of capabilities. The user defined
set would not be interpreted by the kernel, but either by a table lookup
reference monitor, or passed to a daemon for validation. I see them being
used to delegate programmed capabilities (say "add a user to the system")
that may be assigned to a specific program, which can then be passed to
a daemon via some request from program to a daemon to handle. (details of
future use not specified any more than that).

One way to implement a very long list of capabilities was used on the Cray
UNICOS system - Each inode contained a reference to a privlege access list.
The reference is only an index into a table containing the actual list.
It's either 64 or 128 bits long, the default list was 64 bits (the system
defined ones). It gives the administrator the ability to define what
capabilities could be used, and the ability to make global changes without
scanning the entire filesystem. Incidentally, it reduces the load on the
inode by limiting the size of the reference. 8 bits would allow for 255
(reference value of 0 means no capability list assigned)
different capability lists; where each capabilitiy list entry could be
64/128/... whatever a hard upper limit would be. Under UNICOS, I believe the
definition list is loaded during boot (it may even disable the all-powerful
root when loaded, don't know for sure). UNICOS only shows that 29 privileges
are defined out of a maximum of 64.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.031 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site