Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: filenames with a '/'  -- help
Message-ID: <17870@rpp386.cactus.org>
Date: 6 Feb 90 05:26:14 GMT
References: <22167@adm.BRL.MIL> <GUMBY.90Jan23090546@Gang-of-Four.Stanford.EDU> <2845@auspex.auspex.com> <25C7178C.6F8@marob.masa.com>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Distribution: usa
Organization: Lone Star Cafe and BBS Service
Lines: 43

In article <25C7178C.6F8@marob.masa.com> cowan@marob.masa.com (John Cowan) writes:
>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.
>A program (or shared library) would be handed two capabilities to start with:
>one for the root, one for the current directory, and would be able to do
>filename parsing given those operations.
>
>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....

There is no reason to get crypto with this problem, unless you plan on
passing "capabilities" around like candy.  Remember that a file descriptor
is also a "capability" and it doesn't have to be encrypted to be kept
from evil doers.

In the scenario you suggest, the kernel is still performing the directory
lookup, so it can maintain a table of "currently available capabilities".
Kinda like the open file table, only different.  A user requests a file
name translation and receives back an index into their capability table.
They can then hand that "capability" back and request a file descriptor
or whatever.  The in-core inode pointed to by the capability table would
contain all of the permission bits, just as inodes do today.

Two problems arise.  First, we are back to having the kernel perform the
filename to inode translation, so there are going to be "arbitrary"
decisions which someone is going to complain about.  Second, the number
of currently active capabilities would have to be limited on a per-process
basis simply to avoid having someone request a capability for every file
on the system.  The "find" command sounds like a candidate.

Finally, the worst of all this mess is that each component in a filename
must be translated separately, or else an array of pointers to pathname
pieces is going to have to be passed in.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org