descriptors vs pathnames (was Re: getcwd() and friends.)

[Scott Schwartz]

In article <1249 at ncr-sd.SanDiego.NCR.COM>, greg at ncr-sd (Greg Noel) writes:
>In article <4457 at psuvax1.cs.psu.edu> schwartz at shire.cs.psu.edu
>(Scott Schwartz) writes:
>>... what Felix Lee and I are proposing ... is to add two new flags
>>to open....  The flags are O_EXEC ... and O_OPEN ....

After some thought, I think we actually need three flags:
	O_EXEC:  open for execution
	O_STAT:  open for nothing (e.g. so you can fstat mode 0 files)
	O_OWNER: open for owner operations (chown, chmod)

(I am definately on the lookout for creeping featurism at this point :-)

>It's interesting to me how this thread is re-inventing the opaque directory
>object proposed as part of the Secure Multics Project.  

Long past time for me to read Organick, I guess.

>The essential point
>of your proposal is to be able to acquire a handle on some component of the
>file system tree, and then be able to perform operations on it.  In other
>words, you are decoupling the name lookup from the operation. 

In a sense, but not exactly.  Essentially I want unix to be a
capability based system, at least in terms of the filesystem
interface.  So when you get ahold 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.  (You could certainly do it other ways, but I
feel this is the right approach because it is the way read and write
currently operate, and makes some other things easier.)  Enter, unix++.

The (somewhat ongoing) project that inspired these proposed
modifications was an access-control-list server: a uid 0 process that
takes requests for files (the arguments to open, plus some
authentication stuff) and returns descriptors.  The acl server must
decide if it should grant access to each particular file, and how much
access it should grant.

So I could ask the server for an execute mode descriptor to one of
your (mode 700) files, and then execute the file with fexecve.  I need
enough rights to execute the file, but not so many that I could do
anything else with it.  Hence the O_EXEC flag.  Other operations
require more and/or different rights, hence the O_OWNER and O_STAT
flags.

>The new syscalls should modify the file handle passed it, not create a new
>one, so the standard sematics can be easily simulated.

>I don't think you need more than the one new syscall (or one new option to
>the current open) in order to get the results you want; just consider the
>file handle as opaque until it's consumed by another syscall, which has the
>power to modify the attributes as necessary.

This approach has its attractions.  The catch is that I want to
localize the "power to modify the attributes".  When one process gets
an opaque descriptor from another, does it have the right to make
these modifications?

Also, if open is the only call that can create an instance of access
rights (in the form of a file descriptor) then everything is tidy.  In
particular, I don't need any really new syscalls.  Just some cutting
and pasting to convince the old ones that they don't need to call
namei and check access and all the rest.  (Minimizing the extent of
the changes I need for this is a factor.)
-- 
Scott Schwartz		<schwartz at shire.cs.psu.edu>