/dev/fd (was Re: setuid scripts ...)

Marek Michalkiewicz (marekm@i17linuxb.ists.pwr.wroc.pl)
Tue, 1 Oct 1996 20:25:17 +0200 (MET DST)

Larry 'Daffy' Daffner:
> Albert Cahalan writes:
> -> From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
> -> >
> -> > 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

Hmm, for now the only problem would be that file descriptors >255
are not accessible through /dev/fd - everything else should still work
fine. BTW, the current /proc/*/fd has the same limitation (fd == low
8 bits of inode number). And we are moving to a 32-bit dev_t...

> 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).

It's 65536 - should be enough for quite some time :-).

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

One is that these are character devices and don't need to be tainted
(programs like ftpd won't let you read it, avoiding access to ftpd's
open files such as wtmp or /etc/shadow). /proc files look like regular
files even though they really aren't. Also, by opening /dev/fd/n you
get a dup() of the file descriptor - that was the case some time ago
(known as Plan9 semantics) but stopped working later. If it's the way
it works on other systems, we'd better follow that, just in case there
are programs which rely on the standard /dev/fd behaviour...

One disadvantage is that you can't open file descriptors from other
processes - but it's rarely needed, and can be a security problem
if not done right.

The problem still remains: it would be nice to be able to replace
most of the open() function (including get_empty_filp()) with
something driver-specific. But I guess that would require some
changes in the order how things are done - currently we call
get_empty_filp() before open_namei(). (Is this order important?)

> This is not a kernel issue at all. The proc fs can be mounted
> anywhere you like, including multiple places. (Try it :). The only

Yes, I know. That's why I said it's somewhat unrelated :). But it
also gives us a chance to reorganize our /proc and do some things
better without breaking existing programs. Once everyone is using
the new procfs, the old /proc mount point can be used for a SVR4-
like (not just Solaris - it seems that it's at least similar on
Digital Unix, which Linux/Alpha tries to be binary-compatible with)
/proc filesystem if/when that is implemented.