davidb@Pacer.UUCP (David Barts) (12/20/89)
How does /bin/pwd work? There is no kernel call to find your current directory in UNIX, so it has to do some backhanded peeking in memory somewhere, probably in kernel memory. This suspicion is reinforced by /bin/pwd being setuid to root on my system (HP-UX, System V compatible). My guess is that the system uses one of each process's file descriptors to refer to the opened current working directory file, and pwd takes this descriptor and somehow comes up with the name of the file associated with it. This brings up the possibility of doing the following: saved_cwd_fd = dup(cwd_fd); dup2(mystery_fd, cwd_fd); s = getcwd(); /* s now points to name of mystery file */ dup2(saved_cwd_fd, cwd_fd); close(saved_cwd_fd); (At least on our system, getcwd is not a system call; it forks /bin/pwd and reads the current directory from a pipe.) If so, what is the value of cwd_fd for various UNIX systems, especially HP-UX? Or does the system just store the cwd as a string somewhere in the process header? Reply to me and I'll summarize. -- David Barts Pacer Corporation davidb@pacer.uucp ...!fluke!pacer!davidb
budd@bu-cs.BU.EDU (Philip Budne) (12/20/89)
In article <263@zircon.UUCP> davidb@Pacer.UUCP (David Barts) writes: > >How does /bin/pwd work? it stats "." then opendirs ".." and stats each entry until it finds one with the same device and i number, it then does a chdir(".."); This is repeated until "/" and "." are the same. buit2% trapfile /bin/pwd 0x2100: stat("/",0xefff594) 0x227c: stat(".",0xefff594) 0x2438: open("..", 0) -> 3 0x2454: fstat(3,0xefff510) 0x2148: chdir("..") 0x2174: fstat(3,0xefff558) 0x23ea: close(3) 0x227c: stat(".",0xefff594) 0x2438: open("..", 0) -> 3 0x2454: fstat(3,0xefff510) 0x2148: chdir("..") 0x2174: fstat(3,0xefff558) 0x2222: stat(".",0xefff558) 0x2222: stat("..",0xefff558) 0x2222: stat("lost+found",0xefff558) 0x2222: stat("dev",0xefff558) 0x2222: stat("etc",0xefff558) 0x2222: stat("bin",0xefff558) 0x2222: stat("mnt",0xefff558) 0x2222: stat("private",0xefff558) 0x2222: stat("pub",0xefff558) 0x2222: stat("tmp",0xefff558) 0x2222: stat("usr",0xefff558) 0x2222: stat(".cshrc",0xefff558) 0x2222: stat(".login",0xefff558) 0x2222: stat(".profile",0xefff558) 0x2222: stat("usr8",0xefff558) 0x2222: stat("stand",0xefff558) 0x2222: stat("vmunix",0xefff558) 0x2222: stat("lib",0xefff558) 0x2222: stat("private.MC68020",0xefff558) 0x2222: stat("usr1",0xefff558) 0x2222: stat("usr2",0xefff558) 0x23ea: close(3) 0x227c: stat(".",0xefff594) 0x22cc: chdir("/usr2/budd") 0x4d3c: ioctl(1,0x40067408,0xefff76c) Inappropriate ioctl for device 0x3c1c: fstat(1,0xefff78c) 0x38d4: close(0) 0x38d4: close(1) 0x38d4: close(2) /usr2/budd
davidb@Pacer.UUCP (David Barts) (12/22/89)
As numerous responses have told me, the system does not maintain an open file descriptor into the current working directory. Rather, pwd works its way back up the tree by finding the i number of . and searching for the entry under .. whose i-number matches that of dot. Special trickery is needed to handle mount points. /bin/pwd is setuid to root so it can handle unreadable directories in the path. -- David Barts Pacer Corporation davidb@pacer.uucp ...!fluke!pacer!davidb
envbvs@epb2.lbl.gov (Brian V. Smith) (12/22/89)
In article <265@zircon.UUCP>, davidb@Pacer.UUCP (David Barts) writes:
<
< As numerous responses have told me, the system does not maintain
< an open file descriptor into the current working directory. Rather,
< pwd works its way back up the tree by finding the i number of .
< and searching for the entry under .. whose i-number matches that
< of dot. Special trickery is needed to handle mount points.
<
< /bin/pwd is setuid to root so it can handle unreadable directories
< in the path.
This is not true in Ultrix - pwd will fail if it encounters an
unreadable directory in the path.
____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.scott@bbxsda.UUCP (Scott Amspoker) (12/22/89)
In article <4504@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >In article <265@zircon.UUCP>, davidb@Pacer.UUCP (David Barts) writes: >< >< As numerous responses have told me, the system does not maintain >< an open file descriptor into the current working directory. Rather, >< pwd works its way back up the tree by finding the i number of . >< and searching for the entry under .. whose i-number matches that >< of dot. Special trickery is needed to handle mount points. >< >< /bin/pwd is setuid to root so it can handle unreadable directories >< in the path. > >This is not true in Ultrix - pwd will fail if it encounters an >unreadable directory in the path. A quick glance at /bin/pwd shows this is also true for Xenix. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
mike@raven.USS.TEK.COM (Mike Ewan) (12/22/89)
In article <488@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >>This is not true in Ultrix - pwd will fail if it encounters an >>unreadable directory in the path. > >A quick glance at /bin/pwd shows this is also true for Xenix. Out of curiosity I checked the systems here. UTek (4.2BSD) is NOT setuid root nor is the real 4.3BSD VAX here, nor is SunOS4.0 or SunOS4.0.3. -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!tektronix!puffin!raven!mike Tektronix, Inc. Compuserv: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart
fischer@utower.gopas.sub.org (Axel Fischer) (12/24/89)
scott@bbxsda.UUCP (Scott Amspoker) writes: >>< /bin/pwd is setuid to root so it can handle unreadable directories >>< in the path. >> >>This is not true in Ultrix - pwd will fail if it encounters an >>unreadable directory in the path. >A quick glance at /bin/pwd shows this is also true for Xenix. Also not true for Interactive 2.02 (SYSV.3) -Axel -- fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP Bang-Europe : ...!{doitcr,gopnbg,tmpmbx}!utower!fischer Bang-USA : ...!uunet!unido!gopnbg!utower!fischer Too low for zero ...
paul@cscnj.csc.COM (Paul Moody) (12/29/89)
/bin/pwd is not setuid to root for AT&T SYSV 3.1 on the 6386wgs, or UTS on an Amdahl. Paul -- Paul Moody UUCP: rutgers!cscnj!paul Computer Sciences Corporation # the opinions expressed are entirely imaginary #