inode number -> pathname? (4.2BSD)

[Ed Gould]

In article <11465 at brl-tgr.ARPA> phil at 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."