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

[Scott Schwartz]

In article <13550 at ncoast.ORG>, allbery at ncoast (Brandon S. Allbery) writes:

>	fd = open(".", 0);
>	chdir("/tmp");
>	...do something...
>	...root makes /usr/spool mode 0700 owner bin...
>	fchdir(fd);	<-- succeeds

>	chdir("/tmp");
>	...do something...
>	...root changes permissions as above...
>	chdir("/usr/spool/uucppublic");	<-- FAILS!

>There is a distinction.  The permissions on a file are dependent on the
>permissions of each component of the path; 

Ok, but suppose we do add the new functionality to unix.  Is that a
mistake?  Is the functionality in your example undesirable, or just
new? I mean, once you aquire a file descriptor for a directory (or
file) you can read that directory (or file) even if it's permissions
change, right?  So why not permit the process' current directory to be
set via the descriptor as well?

By the way, lest things become confused, what Felix Lee and I are
proposing (at this point) is to add two new flags to open, and some
new syscalls.  The flags are O_EXEC, which opens for execution (used
with fexec, fchdir), and O_OPEN, which opens for nothing in particular
(used with fchmod, fchown).

So the example above would use

	fd = open (".", O_EXEC);

SunOS implements fchdir, and requires that you have search permission
on the directory at the time of the fchdir call.  Is this the right
thing to do (assuming you have the O_EXEC flag, which SunOS doesn't)?
Given that the user has the directory open for execution, is there any
reason to check access again during the fchdir?
-- 
Scott Schwartz		<schwartz at shire.cs.psu.edu>