filenames with a '/' -- help

Guy Harris guy at auspex.auspex.com
Wed Feb 7 05:06:50 AEST 1990


>Not quite.  What 'open' would really do under this scheme would be to accept
>a >capability< for a directory, plus a file name, and return a capability
>for the file in question.  A capability differs from an inode because it
>contains coded information that validates the user's access rights.

I indicated that by "inode" I'd presumed they meant "reference to the
inode"; one such reference could be a file descriptor opened to the file
(modulo, presumably, ways of having file descriptors for directories
"open for searching", and the like), which, in effect, is a capability
to the inode - or, if you will, a reference to a capability to the
inode, the actual capability being stored in the kernel.  Inodes are
rather big, so there's a saving from handing around references to them
rather than handing them around directly.

>A reasonable way to implement capabilities would be to use the inode plus
>some random bits.  For each capability, the kernel must retain a copy of it,
>and whenever a capability is passed in, the kernel checks whether it is
>valid.  This makes Unix permissions syntax easy to arrange by having different
>capability-bit combinations for the various permission rights.  Naturally,
>the relation between the permissions themselves and the bits should be
>protected by a cryptographically strong transformation....

How is this better than just handing around what amounts to references
to those capabilities?  (There are several ways of protecting
capabilities, including simply making them not writable by
non-privileged code, which is what "file descriptors as capabilities"
does.)



More information about the Comp.unix.wizards mailing list