Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!spdcc!merk!alliant!linus!philabs!phri!marob!cowan
From: cowan@marob.masa.com (John Cowan)
Newsgroups: comp.unix.wizards
Subject: Re: filenames with a '/'  -- help
Message-ID: <25C7178C.6F8@marob.masa.com>
Date: 31 Jan 90 16:51:22 GMT
References: <22167@adm.BRL.MIL> <GUMBY.90Jan23090546@Gang-of-Four.Stanford.EDU> <2845@auspex.auspex.com>
Reply-To: cowan@marob.masa.com (John Cowan)
Distribution: usa
Organization: ESCC,  New York City
Lines: 23

In article <2845@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>I presume you [previous poster] mean "'open' would take the inode of a directory
>and the *name* of a file within that directory" - since you way it'd
>take "the inode of a directory" I presume that by "inode" you mean some
>reference to the inode, in which case the "inode of (the) file" is what
>"open" would presumably (more-or-less) return.


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