rsf@Shasta.ARPA (07/08/85)
I am looking for a good way to generate the full path name of a directory, given only its inode number (plus the device number of its filesystem). Does anyone know if there's a good way to do this in 4.2BSD? Clearly, being able to chdir to the directory, given only its device and inode numbers, would be sufficient for my needs. The 'obvious' solution is to open the file system as a device, parse the data structures to find the appropriate inode, and then follow the ".." entries to construct the pathname (this is effectively what "ncheck" does). However, I'd prefer a cleaner solution if at all possible. Also, does anyone know if this is likely to be any easier to do in 4.3BSD? Ross.
guy@sun.uucp (Guy Harris) (07/08/85)
> I am looking for a good way to generate the full path name of a directory, > given only its inode number (plus the device number of its filesystem). > The 'obvious' solution is ... (this is effectively what "ncheck" does). Not only is it the obvious solution, it's the only solution. No version of UNIX currently in existence or coming out in the near future (nor, I suspect, any version you're likely to see) makes it any easier. Guy Harris
tim@ucf-cs.UUCP (Tim Curry) (07/09/85)
From rsf@Shasta.ARPA Sun Feb 6 01:28:16 206 Newsgroups: net.unix-wizards Subject: inode number -> pathname? (4.2BSD) Organization: Stanford University >I am looking for a good way to generate the full path name of a directory, >given only its inode number (plus the device number of its filesystem). >Does anyone know if there's a good way to do this in 4.2BSD? Clearly, being >able to chdir to the directory, given only its device and inode numbers, >would be sufficient for my needs. >The 'obvious' solution is to open the file system as a device, parse the data >structures to find the appropriate inode, and then follow the ".." entries to >construct the pathname (this is effectively what "ncheck" does). >However, I'd prefer a cleaner solution if at all possible. How about: find / -inum inode-number -print -- Tim Curry USENET: decvax!ucf-cs!tim ARPANET: tim.ucf-cs@csnet-relay
phil@RICE.ARPA (William LeFebvre) (07/11/85)
>> I am looking for a good way to generate the full path name of a directory, >> given only its inode number (plus the device number of its filesystem). >> The 'obvious' solution is ... (this is effectively what "ncheck" does). > > Not only is it the obvious solution, it's the only solution. No version of > UNIX currently in existence or coming out in the near future (nor, I > suspect, any version you're likely to see) makes it any easier. I disagree! If it were possible to set the current working directory to a given inode and device, then pwd would give you the answer. All the permission information, and even the bit denoting whether or not this inode refers to a directory is stored in the inode, and can easily be checked in such a call. Putting such a call in would be easy. Just do what "chdir" (well, actually "chdirec" in 4.2) does after it calls "nami". Why is this hard? Now, what would be hard would be generating the full path name for an arbitrary file given just the inode and device. The only program that can do that is find, and I strongly suspect that that will never change in the near or far future. Doing so would violate one of the founding principles of the Unix file system. But with a directory, you know that (save symbolic links) there is one unique path name for that directory. William LeFebvre Department of Computer Science Rice University <phil@Rice.arpa> or, for the daring: <phil@Rice.edu>
phil@RICE.ARPA (William LeFebvre) (07/11/85)
> Ahh! Now you changed the rules! (and only want directories). You could > backtrack thru .. which is what pwd does but it still is a bit irksome, I did not change the rules! The original article stated: "I am looking for a good way to generate the full path name of a directory..." Looks to me like he said "path name of a directory". As I said in my previous message, this problem is much, much harder to solve for any arbitrary file. > By the way, UNIX does not limit a directory to have a unique pathname, > but rmdir, mvdir, ln, and mkdir try to make it look like it does. If > you are superuser and write your own little C program you can make > extra links to a directory. It is true that the Unix *kernel* does not limit directories to a single pathname. Neither does the kernel require the two filenames "." and ".." to be the first two names in a directory. Nor does it require that file descriptors 0, 1, and 2 be used for standard input, output, and error, respectively. Yet all three of these characteristics are considered to be part of the overall Unix system. They are conventions that should be adhered to. Are you claiming that "rmdir, mvdir, ln, and mkdir" are not part of Unix? Clarification: the "mkdir" system call does make "." and ".." in the directory it creates. But "mknod" with the right bits doesn't. And under 4.1, "mv" was setuid to root so that directories could be moved. The only way to move them was by linking and unlinking them, and only root can do that. There was no "rename" call in 4.1. BUT the kernel doesn not require that a directory always have "." and "..". Root can easily unlink them! Yes you can have five different names all pointing to the same directory inode, but ".." can only point back to one of them. And if you really are crazed enough to do this, you had better make sure your Unix system never crashes again, because "fsck" will get gastric distress trying to digest the spaghetti file system it will find. Urp! Such a file system is just really disagreeable to many parts of Unix, even though the kernel lets you get away with it. See? I know my Unix. William LeFebvre Department of Computer Science Rice University <phil@Rice.arpa> or, for the daring: <phil@Rice.edu>
dan@rna.UUCP (Dan Ts'o) (07/11/85)
In article <> phil@RICE.ARPA (William LeFebvre) writes: >>> I am looking for a good way to generate the full path name of a directory, >>> given only its inode number (plus the device number of its filesystem). >>> The 'obvious' solution is ... (this is effectively what "ncheck" does). >> >> Not only is it the obvious solution, it's the only solution. No version of >> UNIX currently in existence or coming out in the near future (nor, I >> suspect, any version you're likely to see) makes it any easier. > >I disagree! If it were possible to set the current working directory >to a given inode and device, then pwd would give you the answer. All >the permission information, and even the bit denoting whether or not >this inode refers to a directory is stored in the inode, and can easily >be checked in such a call. Putting such a call in would be easy. Just >do what "chdir" (well, actually "chdirec" in 4.2) does after it calls >"nami". Why is this hard? Do you mean create a system call ichdir(inode, device) just so that pwd can tell you the path of a directory ? Besides this concept breaks the documented semantics of chdir() and directory protection: No, not all the info of protection is contained in the inode, for directories all directories leading to that directory must be accessible for chdir() and the like. Granted this behavior should not be counted upon for the real security conscious. If the user is not root, then I'm not sure he should be allowed to find the full path of a directory given the inode and device. If he is root, he can use ncheck or write a version of pwd which reads the device raw like ncheck and simulate the algorithm ichdir(inode, device), stat("..") ... (loop) just like pwd. It might be faster than ncheck. > >Now, what would be hard would be generating the full path name for an >arbitrary file given just the inode and device. The only program that >can do that is find, and I strongly suspect that that will never change >in the near or far future. Doing so would violate one of the founding Huh ? ncheck gets pathnames just fine given the inode and device. But maybe you mean within the confines of the Unix file system. But a ichdir() based on inode/device is hardly within the confines of the UNIX filesystem. Or maybe you mean it could be non-unique (but find would also return multiple answers and directories...) >principles of the Unix file system. But with a directory, you know >that (save symbolic links) there is one unique path name for that >directory. Although this is usually true it is possible in most UNIX systems to get directories with multiple hard links, either by accident or on purpose. This behavior should then not be counted on too strongly.
chris@umcp-cs.UUCP (Chris Torek) (07/12/85)
>>> I am looking for a good way to generate the full path name of a directory, >>> given only its inode number (plus the device number of its filesystem). >>> The 'obvious' solution is ... (what "ncheck" does). >> Not only is it the obvious solution, it's the only solution. No version of >> UNIX currently in existence or coming out in the near future (nor, I >> suspect, any version you're likely to see) makes it any easier. > I disagree! If it were possible to set the current working directory > to a given inode and device, then pwd would give you the answer. All > the permission information, and even the bit denoting whether or not > this inode refers to a directory is stored in the inode, and can easily > be checked in such a call. Putting such a call in would be easy. Just > do what "chdir" (well, actually "chdirec" in 4.2) does after it calls > "nami". Why is this hard? It's "hard" because the difference between chdir and set_my_cdir_inode is that chdir checks permissions along the *entire pathname* leading to the ultimate inode that will sit in u.u_cdir. (Of course you could restrict the set_my_cdir_inode syscall to the super user....) Even putting code in the kernel to do what pwd does, and making it check permissions on all the parent directories, wouldn't be right as when you log in you get to your home directory by a chdir by uid 0, so there's no guarantee that any higher level directories are accessible (anymore). > Now, what would be hard would be generating the full path name for > an arbitrary file given just the inode and device. ... But with > a directory, you know that (save symbolic links) there is one unique > path name for that directory. Actually, you don't "know" it, but you sure hope it's true.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
tmb@talcott.UUCP (Thomas M. Breuel) (07/12/85)
> I disagree! If it were possible to set the current working directory > to a given inode and device, then pwd would give you the answer. All > the permission information, and even the bit denoting whether or not > this inode refers to a directory is stored in the inode, and can easily > be checked in such a call. Putting such a call in would be easy. Just > do what "chdir" (well, actually "chdirec" in 4.2) does after it calls > "nami". Why is this hard? > > William LeFebvre That's probably not a good idea. Many people/programs rely on the fact that files within or below an inaccessible directory are inaccessible regardless of their modes. Although there is in principle nothing wrong with the idea of introducing a set of system calls that work by inode rather than by name, it is incompatible with current habits and uses of the file system. Thomas.
donn@utah-gr.UUCP (Donn Seeley) (07/12/85)
No one has mentioned the obvious solution to this impasse... (1) Get 'V8' (occasionally solecized to 'Eighth Edition Unix' :-). (2) Implement a variant filesystem called /inode (a la /proc). To access an arbitrary inode i with major device number m and minor device number n, one merely opens /inode/m/n/i. (3) To associate a directory with a known inode number to a pathname, change directory to /inode/m/n/i (m, n and i as above) and run 'pwd'. (4) Cringe at the security implications of this proposal. Step (1) is obviously the tough one... Step (3) illustrates an asymmetry between directories and regular files (the latter are still very difficult to locate under this proposal). Haven't tried this myself, Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
guy@sun.uucp (Guy Harris) (07/12/85)
> >I am looking for a good way to generate the full path name of a directory, > >given only its inode number (plus the device number of its filesystem). > How about: > > find / -inum inode-number -print Well, this is even slower than "ncheck", and will report *all* files that have that inumber; remember, the problem was "translate a device/inumber *pair* to the directory with that inumber *on that device*". Guy Harris P.S. 4.xBSD is the only UNIX that documents "-inum" but I think it's been in there since V7 and is thus in S3 and S5 as well.
henry@utzoo.UUCP (Henry Spencer) (07/12/85)
> ... If it were possible to set the current working directory > to a given inode and device, then pwd would give you the answer. All > the permission information, and even the bit denoting whether or not > this inode refers to a directory is stored in the inode, and can easily > be checked in such a call... This proposal has the side effect of making a significant change to the semantics of Unix file protection. The permission bits on a Unix directory are *not* sufficient for permission checking, because the permissions of the directories above it in the tree also matter. It can be done the other way, where parent permissions don't matter -- I think Multics did it that way -- but this would require changes to both programs (notably mkdir, which would have to tighten up directory permissions) and user habits (making your home directory private no longer suffices to make everything under it private). -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
larry@MITRE.ARPA (07/12/85)
>write one to some people at DEC. Then I found that PIP command that >allowed linking dirs (MCR PIP NEW=OLD/LI ?? trivia quiz.) I got ill >and flamed about why they should hire computer scientists at least >once in a while to help the VMS developers understand the >differences between a tree and a cyclic graph (I still use this as >an example when I teach data structures.) > >I blushed when I found it in UNIX, although I admit the discouragements >are much more obvious. > > -Barry Shein, Boston University Who ever said a directory stucture had to be a "TREE" ?? -Larry.
andrew@orca.UUCP (Andrew Klossner) (07/14/85)
[]
"If it were possible to set the current working directory to a
given inode and device, then pwd would give you the answer.
All the permission information, and even the bit denoting
whether or not this inode refers to a directory is stored in
the inode, and can easily be checked in such a call."
The permission information is distributed throughout the path to the
directory. If /usr/fred is mode 0700, then the fact that
/usr/fred/sources is 0755 should not be construed as sufficient reason
to allow another user to chdir to /usr/fred/sources.
-=- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]levy@ttrdc.UUCP (Daniel R. Levy) (07/14/85)
guy@sun.uucp (Guy Harris) <2414@sun.uucp>: > >> >I am looking for a good way to generate the full path name of a directory, >> >given only its inode number (plus the device number of its filesystem). >> How about: >> >> find / -inum inode-number -print > >Well, this is even slower than "ncheck", and will report *all* files that >have that inumber; remember, the problem was "translate a device/inumber >*pair* to the directory with that inumber *on that device*". > > Guy Harris > >P.S. 4.xBSD is the only UNIX that documents "-inum" but I think it's been in >there since V7 and is thus in S3 and S5 as well. > 'Scuse me, Guy (I've been landed on with both feet before by several users when I asked a mild question about something you said earlier, so I am try- ing to be cool about this) but why not find /file_system -inum inode_# -print [maybe -exec ls -l {} \;] which would restrict the search for the inum to the file system on the device in question? That would be a bit quicker than searching all filesystems, as a find on root would do. A mount command would show what's mounted on what, so you'd know which filesystem to search. Sorry if I misunderstand. Please readers if you answer don't just holler 'Guy knows his Unix' this time. Maybe it's still slower than ncheck (I haven't timed it yet). thanks. dan levy at&t teletype corp skokie ill ..!ihnp4!ttrdc(!ttbcad)!levy
jack@boring.UUCP (07/15/85)
Adding a system call to set the current directory to a given inode/device pair is not only dirty, it also messes up security. It is possible to create a directory in which a user has all permissions, but which he cannot reach, because the parent directory is unsearchable. This can be a very useful feature at times. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (07/15/85)
>>From: larry@MITRE.ARPA >>Subject: Re: inode number -> pathname? (4.2BSD) >> >>write one to some people at DEC. Then I found that PIP command that >>allowed linking dirs (MCR PIP NEW=OLD/LI ?? trivia quiz.) I got ill >>and flamed about why they should hire computer scientists at least >>once in a while to help the VMS developers understand the >>differences between a tree and a cyclic graph (I still use this as >>an example when I teach data structures.) >> >>I blushed when I found it in UNIX, although I admit the discouragements >>are much more obvious. >> >> -Barry Shein, Boston University > > Who ever said a directory stucture had to be a "TREE" ?? > > -Larry. You are right, they don't have to be trees. Maybe we should use some non-deterministic algorithm altogether. Ok, no sarcasm, but searching trees is a *little* easier than more generalized graphs...c'mon...yes you can do anything, but it doesn't mean it's necessary. -Barry Shein, Boston University
phil@RICE.ARPA (William LeFebvre) (07/16/85)
Many many people have now pointed out that chdir-ing directly to an
inode circumvents the security of scanning a path. It hadn't occurred
to me at the time, but that is quite correct. So, such a call would
have to be limited to the super-user. I can see no other way around it.
Oh, and by the way, even "find" on just one partition is very slow. It
just doesn't cut it when you're in a hurry.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.arpa>
or, for the daring: <phil@Rice.edu>guy@sun.uucp (Guy Harris) (07/16/85)
> ...why not > > find /file_system -inum inode_# -print [maybe -exec ls -l {} \;] > > which would restrict the search for the inum to the file system on the > device in question? Unfortunately, if something is mounted on a directory on /file_system, it will also search that file system. The 4.3BSD "find" may have a file to keep it from wandering across file systems. > Maybe it's still slower than ncheck (I haven't timed it yet). On my machine - Sun-2/120, SCSI disk, running Sun UNIX 2.0 (4.2BSD based) - I tried doing a "find /usr/src -inum..." ("/usr" is the file system, but I wanted to keep it from wandering onto other file systems) and an "ncheck". In this case, the "find" was faster. I don't know whether a find starting at /usr would have been slower than "ncheck" (I doubt it, since most things on /usr on my machine other than /usr/src are only a couple of levels deep). On the other hand, my /usr/src is not a complete UNIX source tree; trying it on a big Eagle-based file system might give different results. However, neither one is fast; the "find" took about 50 seconds from the time "time" fired it off to the time I hit my interrupt key after it printed the path name I was looking for. Guy Harris
ed@mtxinu.UUCP (Ed Gould) (07/16/85)
In article <11465@brl-tgr.ARPA> phil@RICE.ARPA (William LeFebvre) writes: > ... If it were possible to set the current working directory >to a given inode and device... All >the permission information, and even the bit denoting whether or not >this inode refers to a directory is stored in the inode, and can easily >be checked in such a call. Putting such a call in would be easy. Just >do what "chdir" (well, actually "chdirec" in 4.2) does after it calls >"nami". Why is this hard? It's not hard, but it violates the protection model of the Unix filesystem. Unix protection is based not only on the permissions of a file itself, but on the permissions of *all* of the directories in the path leading to the file. Consider the following: drwx------ 3 ed mtxinu 512 Jul 16 09:58 a drwxr-x--- 3 ed mtxinu 512 Jul 16 09:58 a/b drwxr-xr-x 2 ed mtxinu 24 Jul 16 09:58 a/b/c Directory a/b/c has read and execute permissions for everyone, so it might seem that anyone could access the files in it. In fact, only "ed" can access it because of the permissions on directory a. (Of course, there are ways that ed or the super-user could *allow* others to access a/b/c - even with the permissions as they are shown - but that's not the point here.) >Now, what would be hard would be generating the full path name for an >arbitrary file given just the inode and device. The only program that >can do that is find, and I strongly suspect that that will never change >in the near or far future. Doing so would violate one of the founding >principles of the Unix file system. But with a directory, you know >that (save symbolic links) there is one unique path name for that >directory. Founding principles? I don't think so. If I remember correctly, the first Unix allowed multiple, arbitrary links to directories. Since the filesystem was essentially constructed by hand, this wasn't a real problem. Only after more facilities were added to the system to manipulate the filesystem, and checking programs like icheck and dcheck were written, was the "strict tree" restriction added. The ncheck program is the fastest way to do the inode-to-name search, although the solutions using find will work, too. Ncheck is faster because it reads the disk and decodes the filesystem itself, rather than using the kernel to do the work. It must have permission - usually granted only to the super-user - to do this, however. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
tim@cithep.UucP (Tim Smith ) (07/18/85)
find /file_system will search the specified file system AND all file
systems that are mounted on a directory within the specified file system.
On my systems, I run ncheck out of crontab once a night on all filesystems.
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim