robert@cheviot.uucp (Robert Stroud) (08/20/85)
Pat Place reports a rather complex situation in which pwd fails and apparently
gives an infinite loop. In fact the bug he describes has been fixed in 4.2
but there is a similar bug which has not been fixed. There is also a simpler
way of reproducing both bugs.
The problems are caused by "pwd" or "getwd" not checking the return code
on various system calls, and may be reproduced as follows:
Go into a sub-directory whose parent you own, e.g.
cd /tmp ; mkdir 1 1/2 ; cd 1/2
-----------------------------------------------------------------------------
Original Problem
chmod 400 .. ; pwd
4.2 correctly reports "pwd: getwd: cannot chdir to .."
V7 and other versions that do not check the return code on the chdir("..")
call will loop until the output buffer has been filled. The code checks that
it can open ".." which only requires read permission but not that it can
chdir to ".." which requires execute (or search) permission.
PNX on my Perq says "panic: kernel address error"!! (:-)
------------------------------------------------------------------------------
New Problem
chmod 400 . ; pwd
4.2 and other versions which do not check the return code on the stat(".")
call will report "/" because the same buffer has just been used to stat "/"!
Somebody fixed "getwd" to check some, but not all of the return codes!
-----------------------------------------------------------------------------
The fix to both problems is obvious. I'm not sure what will happen with
shells that have the pwd algorithm built in, but some programs which have
the algorithm built in are liable to loop (e.g. rn).
Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.
UUCP ...!ukc!cheviot!robert
ARPA robert%cheviot.newcastle@ucl-cs.ARPA
JANET robert@newcastle.cheviotpat@ist.UUCP (Patrick Place) (08/26/85)
[]
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2
/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir2/dir3
The above was the output of pwd, caused by the following sequence of events.
Note that the above should be all one line.
1) Create directories dir1, dir1/dir2, dir1/dir2/dir3
2) chmod o+r dir1 such that dir1 has permission rwx---r--
3) cd dir1/dir2/dir3
4) su to some id not in the owners group.
5) pwd.
Note that this is not the way I discovered this bug, simply a way
in which it can be demonstrated. The bug appeared during my normal
use of Unix.
Note that if dir1 had permission rwx------, then pwd produced the
expected "cannot open .." message.
--
Patrick Place {inset, root44, mcvax, qtlon}!ist!pat
Imperial Software Technology, London England