To find out the names of open files in a process

[Russell Kent]

in article <904 at thorin.cs.unc.edu>, gallmeis at wasp.cs.unc.edu (Bill Gallmeister) says:
> I promised myself I wouldn't get into this.  So here I am.  What's wrong
> with rewriting the library routines so they squirrel away file names +
> file statistics, then pass them over when the process gets migrated?  It
> really seems that the mapping of filename to inode can be done outside
> of the kernel.  And therefore should be.  Run the processes under control
> of a "puppet master" that knows how to do these things.  Much better than
> modifying the kernel, although it doesn't look quite as good on the resume...
> Bill O. Gallmeister					gallmeis at cs.unc.edu

Migrating the pathname to inode number translation from the kernel into
the user space would:

	1. Eliminate some of the file access security afforded by the
	   present scheme.

	2. Destroy the orthogonality of the physical resource naming

Explanations:
	As we all know, the kernel uses the execute bit (x bit) of a directory 
	to allow "search" permission, as opposed to "read" permission which
	is still handled by the read bit (r bit).  Presently, it is possible to
	construct to path types which I will call "under glass", and "blackhole."

	An "under glass" pathname is one in which the terminal directory
	(ie next-to-last pathname component) is readable, but not searchable.
	This allows programs to see that the file exists, but does not
	allow it to open the file (the clever reader will note that this is
	easily accomplished with the permissions on the file itself -- I never
	said that this was a _useful_ technique 8-).

	A "blackhole" pathname is on in which at least one of the directories
	in the pathname is searchable but not readable.  This allows programs
	to access the file _if_ they already know the pathname.  Since the
	directories are not readable, then (with some careful naming) the
	file is effectively inaccessible unless the name is already known.
	This can be used where the other security techniques provided by
	the system are ineffective, awkward, or have potentially unpleasant
	side-effects.  (SA's golden rule: every setuid root program is a
	potential disaster)

    These are admittedly esoteric objections; but what about that
	panacea for nearly all security problems: chroot().  How
	will you implement this if the user/kernel open is done
	with inode numbers? (Of course, the _truely_ mischievous user
	can be dealt with by more extreme measures such as putting his/her
	home directory on /dev/tape 8-).

	As for the orthogonality of the name space of physical resources,
	I can best demonstrate with a question: What is the inode number
	of /dev/ra0a? Or of /dev/tty03?
-- 
Russell Kent                    Phone: +1 214 995 3501
Texas Instruments               UUCP address:
P.O. Box 655012   MS 3635       ...!convex!smu!tifsie!kent
Dallas, TX 75265                ...!ut-sally!im4u!ti-csl!tifsie!kent