Re: setuid scripts (was Re: proc fs and shared pids)

Larry 'Daffy' Daffner (
Sun, 29 Sep 1996 21:11:27 -0500

Albert Cahalan writes:
-> From: Marek Michalkiewicz <>
-> >
-> > Or maybe we should start working on a "real" /dev/fd filesystem as
-> > found on Solaris (possibly other systems too, but I can't check right
-> ...
-> > One nice thing about these files is that they are really character
-> > devices (minor number == fd number), and so they don't need to be
-> Then fd numbers are limited by the biggest minor number.

Well, the largest fd number and the largest major mumber are the same
in the default configuration (Although you'd seriously PO the people
that bump the maxfd up to 1024). Also, wasn't there talk about
expanding the major/minor device numbers? Seems to me this would be
additional motivation for both, and I don't see systems wanting >
65,568 open files (assuming that the minor number becomes 16 bits).

The question is, what advantages does /dev/fd/* have over
/proc/self/fd/* ?

-> > [Another idea, somewhat unrelated: start moving /proc to a new location,
-> > so that it doesn't conflict with Solaris /proc, if someone ever implements
-> > that for more binary compatibility between SparcLinux and Solaris.

This is not a kernel issue at all. The proc fs can be mounted
anywhere you like, including multiple places. (Try it :). The only
issue here is to convince developers of code which uses the proc fs
and distribution managers to switch to a new location. If you want to
get the ball rolling on this one, bring it up to the FSSTND group (Or
whatever they're calling themselves these days). Once the location of
the proc fs is changed in the standards, people SHOULD start using the
new location, and there can always be a symlink from /proc to the new
location, as someone suggested.


  Larry Daffner        |  Linux: Unleash the workstation in your PC! /
There is nothing so terrifying as ignorance in action. 
	-- Col Jeff Cooper