POPEN(III) in V7 Stdio
ucbvax!unix-wizards
RE: The idea of making "popen" close all file descriptors except 0, 1, and 2
We are running 4.1BSD on VAXen here. Some time ago, we discovered a maddening
bug in "popen". If you have two concurrent "popen" processes and are writing
down a pipe to the first one, you cannot cause an EOF on the first pipe while
the second process is still around. This is because the second process has
(quite obliviously) inherited the first process's pipe.
The solution someone here came up with was to have "popen" keep a static array,
indexed by file descriptor number, in which each pipe produced by "popen" would
be associated with the process number of the corresponding child process. When
a second (third, etc.) "popen" was issued, this array would be scanned and any
active pipes would be closed in the new child process. When a child exited,
"pclose" would search for, and clear out, the appropriate array entry.
This is admittedly more work than simply closing everything except stdin,
stdout, and stderr, but at least it seems to do the minimum necessary action
required to fix the problem.
I guess my only reservation about having "popen" close everything in sight is
that someone might want to run a program in which an open file is passed via a
known file descriptor other than 0, 1, or 2. Since such programs are quite
rare in UNIX, though, maybe it would be OK to force the person to use "fork"
and "exec" manually in such cases.
-- Rich
ucbvax!unix-wizards
In-real-life: Steven M. Bellovin
I don't much like the idea of changing something like popen, though
I confess I can't think of anything that your suggestion would break.
But let me take this opportunity to push one of my pet causes: the
under-use of FIOCLEX, which causes an open file to be closed after
a successful exec() call. For one thing, it closes a security hole
(does *your* version of Adventure close the cave file during a
shell escape); also, it prevents problems with programs running out
of file descriptor slots.