Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!arosen@hawk.ulowell.edu
From: arosen@hawk.ulowell.edu (MFHorn)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <12625@swan.ulowell.edu>
Date: 5 Apr 89 02:06:35 GMT
References: <811@mtxinu.UUCP>
Sender: news@swan.ulowell.edu
Lines: 26

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()?

There is a function in the BSD kernel called iaccess() that is called
every time one of these (and maybe other) system calls are made.  It
is passed a pointer to an inode struct and the type of access being
requested (read, write, execute).

I see no compromise in security.

--
Andy Rosen           | arosen@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
		RD in '88 - The way it should've been