getcwd() and friends.

[daniel.r.levy]

In article <811 at mtxinu.UUCP>, ed at mtxinu.COM (Ed Gould) writes:
<  >>One thing that really would make things a lot easier would be a fchdir()
<  >>call, that took a file descriptor and tried to chdir to it.
<  >However ... all of the information needed for a chdir() is not present
<  >in the file descriptor.  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().

Umm, somehow SUNOS 4.0 manages to have a fchdir(), without creating a gaping
security hole.  I tested it; it won't let me fchdir() into a mode 444 directory
even though I can open a file descriptor for reading onto that directory.
Granted, it has no way of knowing the search path, and could get you into a
directory, still having execute permission to you, that you had successfully
opened earlier but which you could not open now.  But you could also have
fork()'ed earlier and had the child chdir() into the once-accessible directory,
or into its parent if the directory were read-only then and only now has become
searchable.  Then you could communicate with that child process via some
interprocess communication method to get it to do its dastardly deeds, so
the fchdir() "hole" isn't any more of a hole than exists already.

Note: SUNOS 4.0 also allows fchdir() to be disabled, by means of turning
on auditing.  The call will always fail in this case.
-- 
Dan'l Levy                 UNIX(R) mail:  att!ttbcad!levy, att!cbnewsc!danl
AT&T Bell Laboratories
5555 West Touhy Avenue     Any opinions expressed in the message above are
Skokie, Illinois  60077    mine, and not necessarily AT&T's.