lkml.org 
[lkml]   [2000]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Capabilities
 corbet-lk@eklektix.com (Jonathan Corbet):
>Just for the sake of discussion, I would like to toss out this idea one
>more time. VMS handled the association of privileges (i.e. "capabilities")
>via a central database. For any executable to run with privilege, it had
>to be "installed" as a "known image," with the privileges spelled out.
>Executables so installed were protected from modification thereafter.
>
>This approach eliminates the problem of finding the programs with
>capabilities - they are all listed in one place. There are no issues with
>privileged programs on remotely mounted filesystems. It works with all
>filesystem types, and should not require changes to any of them.
>Implementation should be relatively simple.

VMS had a lot going for it.. except company support (it was overpriced).
The VMS filesystem only allowed one link to a file. If a second occured,
then it was listed as an error. The central database assumed that the
only path to a program was the one it was registered with. Now if it used
the inode, maybe. But what about mountable file systems. If a mount point
moved, does that mean the registry also changed? VMS didn't allow privleged
programs to reside anywhere except the system disk. If this were acceptable
then my idea of a file on each filesystem containing a table of known
capability lists (indexed by device:inode) would work. If you wanted to
eliminate most of the searching, then change the inode to contain the index
of the cpability file to the capability corresponding to the inode. If the
index is zero, then no lookup is required. If nonzero then it is the
index to the capability list for that inode.

This would also allow for "shared" capability lists where the administrator
could change the capability list for all programs that used a particular
index value on the filesystem. It also cuts down on the inode load by
using an unsigned byte or short integer for storing the index. A byte would
allow for a maximum of 255 different capability lists, a short 32765.

There really shouldn't be 32K privileged programs, and I suspect that 255
would be sufficient.
-------------------------------------------------------------------------
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.446 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site