Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <13550@ncoast.ORG>
Date: 11 Apr 89 00:12:29 GMT
References: <811@mtxinu.UUCP> <12625@swan.ulowell.edu>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 51

As quoted from <12625@swan.ulowell.edu> by arosen@hawk.ulowell.edu (MFHorn):
+---------------
| From article <811@mtxinu.UUCP>, by ed@mtxinu.COM (Ed Gould):
| >  >It is possible to be handed a file descriptor
| >  >which you would not be able to have opened because some component of
| >  >the search path denies access now, but at some point in the past did
| >  >allow access.
| > 
| > Worse than that, the permission required to open a directory is "r"
| > (since one may not open a directory for writing), whereas the
| > permission required to change to one is "x".  Hence, Unix protection
| > would be completely violated by the existance of fchdir().
| 
| Why can't the kernel check access permissions *at the time* of the
| fchdir() call just like it does for chdir() and open()?
+---------------

Because it can only check access to the specific inode -- *not* to the path
to the inode.  What happens if you have:

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

BUT, under the present system:

	chdir("/usr/spool/uucppublic");
	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; which means that two (hard) links
to a file may have different *effective* permissions, if (say) one link is
in a directory which is mode 0700 owner root and the other is in /tmp (mode
0777, or maybe 2777 or 3777 on more recent systems), *regardless* of the
permissions on the file.  (Symbolic links are another matter; a symbolic
link contains a path, the permissions of whose components must be figured
into it.  Interestingly, a symlink itself has no relevant permissions; every
one I've seen lstat()'s as mode 0000....)

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser