Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!nosc!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: comp.unix.wizards
Subject: Re: descriptors vs pathnames (was Re: getcwd() and friends.)
Message-ID: <1265@ncr-sd.SanDiego.NCR.COM>
Date: 17 Apr 89 20:35:48 GMT
References: <4457@psuvax1.cs.psu.edu> <1249@ncr-sd.SanDiego.NCR.COM> <4468@psuvax1.cs.psu.edu>
Reply-To: Greg.Noel@SanDiego.NCR.COM (Greg Noel)
Organization: NCR Corporation, Rancho Bernardo
Lines: 45

In article <1249@ncr-sd.SanDiego.NCR.COM>, I write:
>It's interesting to me how this thread is re-inventing the opaque
>directory object proposed as part of the Secure Multics Project.  

In article <4468@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu
(Scott Schwartz) writes:
>In a sense, but not exactly.  Essentially I want unix [sic] to be a
>capability based system, at least in terms of the filesystem
>interface.  So when you get ahold [sic] of a handle on a filesystem object
>(via a descriptor) you hold both a handle on the object and a set of
>rights to manipulate it.  ... [ more description/justification deleted ]

Humpf....  I guess that's what I get for posting while I was tired and
not taking the time to express myself well.  Your description is an
\excellent/ one of the opaque directory objects -- I couldn't have
described it any better.  The only difference is that you want to have
the permissions established a priori rather than when the object is
evaluated.

Opaque directory objects were motivated by the desire to be able to
hide the layout of a file system from an external program -- in other
words, so that you couldn't pass information from the secure side to
the unsecure side by exploring the directory set up.  You were allowed
to create a handle on an object that you couldn't look inside.  You
could request operations on the object (add file name components and
so forth), but until you tried to instantiate the object, you had no
idea if it was valid or not.  Another way of saying this is that the
permissions of the object accumulated as it was manipulated, but were
not visible externally until you tried to use it -- the equivalent
here would be to open it or chdir to it.

My point here is that the permissions required are an intrinsic part
of the \use/ of an object, not of the evaluation of its name.  You
will have to track the permissions so you can do the right thing when
the handle is instantiated, but, abstractly, it's not necessary to
know what permissions will eventually needed.  (Efficiency it a
different issue; it may indeed be useful to provide hints to speed
up the process.)

Oh, and I don't think you'll find it in Organick; this particular
proposal was much later.  It may not have ever been formally published;
I think I read it as part of a DARPA work proposal.  Perhaps there's
a collector of Multics papers that can say.....
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd