inode number -> pathname? (4.2BSD)

[Dan Ts'o]

In article <> phil at 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.