peter@vd.volvo.se (Peter Hkansson) (10/15/89)
not by doing 'system pwd' or something like that but by a system call. To use a library call would mean to use a system call en the end (all library routines uses system calls in the end ??),so that would not answer my question. Please brief me about this subject.
cpcahil@virtech.UUCP (Conor P. Cahill) (10/16/89)
In article <166@volvo.vd.volvo.se>, peter@vd.volvo.se (Peter Hkansson) writes: > not by doing 'system pwd' or something like that but by a system call. > To use a library call would mean to use a system call en the end > (all library routines uses system calls in the end ??),so that would > not answer my question. If I understand your question, you want to determine your present working directory from within a program. The only mechanism you can use is to get the inode of the current directory (.) and look up that inode in the current directories parent (..) and so on and so forth, properly handling the crossing of mount points and stopping at the root of all evil. The system V solution is to call the getcwd (i think) library function which calls the pwd program and saves the output in a string, a pointer to which is returned to the calling function. The bsd solution is to write the routine into the library call and to have the program call the library call. BTW - there is no system call to do this because the system doesn't know where you are (other than the inode of your current directory). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
cspencer@spdcc.COM (Cliff Spencer) (10/16/89)
Speaking of pwd, I wrote a program that prints the current working directory of each process running on a system. If there's any interest I could post it. It runs on 4.3/sun3.5/ultrix 3.0. Send me email if you're interested. -cliff -- Cliff Spencer spdcc!lemming!cspencer lemming!cspencer@spdcc.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/16/89)
In article <1281@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >BTW - there is no system call to do this because the system doesn't know >where you are (other than the inode of your current directory). More accurately, the inode defines WHERE you are, but not how you got there. Note that the usual getcwd() methods return A path from the root, not THE path you used. Some shells (e.g. the one I maintain) keep track of how you reach your c.w.d., and some (e.g. ksh) even keep track of it in a variable. If the c.w.d. could reliably be trusted to be in an environment variable, then an alternate, and generally less confusing, implementation of getcwd() suggests itself. However, it wouldn't be reliable from a security standpoint.
gsf@ulysses.homer.nj.att.com (Glenn Fowler[drew]) (10/17/89)
In article <11310@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <1281@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >BTW - there is no system call to do this because the system doesn't know > >where you are (other than the inode of your current directory). ... > If the c.w.d. could reliably be trusted to be in an environment variable, > then an alternate, and generally less confusing, implementation of getcwd() > suggests itself. However, it wouldn't be reliable from a security standpoint. the environment c.w.d. can be verified by two quick stat()'s at the top of getcwd(): /* NOTE: $PWD could be . */ if ((pwd = getenv("PWD")) && *pwd == '/' && stat(".", &dot) != -1 && stat(pwd, &cwd) != -1 && dot.st_dev == cwd.st_dev && dot.st_ino == cwd.st_ino) { /* pwd is a rooted path to c.w.d. */ } is there some security issue missing here? -- Glenn Fowler (201)-582-2195 AT&T Bell Laboratories, Murray Hill, NJ uucp: {att,decvax,ucbvax}!ulysses!gsf internet: gsf@ulysses.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/17/89)
In article <12291@ulysses.homer.nj.att.com> gsf@ulysses.homer.nj.att.com (Glenn Fowler[drew]) writes: >the environment c.w.d. can be verified by two quick stat()'s at the top of >getcwd(): Yes, it could, but when the stat check fails then you'd have to resort to one of the other methods; getenv("PWD") in itself is insufficient.