On Thu, May 26, 2005 at 03:16:12PM +0400, Dmitry V. Levin wrote:
Hi,
On Thu, May 12, 2005 at 01:57:45AM -0700, Paul Eggert wrote:
address@hidden POSIXLY_CORRECT
+If standard input is a terminal, it is closed so that terminal
+sessions do not mistakenly consider the terminal to be used by the
+command. However, this step is skipped if @env{POSIXLY_CORRECT} is
+set since @acronym{POSIX} requires standard input to be left alone.
Maybe it would be more wise to redirect standard input to /dev/null
instead of just closing it?
Absolutely, programs should normally not leave FDs 0 1 or 2 closed,
because this is a potential security problem. For example, code like
this can accidentally corrupt its output file:-
FILE * f = fopen ("/tmp/foo.txt", "w");
if (f)
{
if (!frob ())
{
fprintf (stderr, "Failed to frob.\n");
return;
}
fclose(f);
}
If the program is executed with FD 2 closed, it will corrupt its
output file when frob() fails. See for example the patches made to
OpenBSD in 1998 to fix this problem and the BugTRAQ advisory on the
same subject in 2002. The relevant patch to OpenBSD is
http://anoncvs.openbsd.lt/cgi-bin/viewcvs.cgi/src/sys/kern/kern_exec.c.diff?r1=1.19&r2=1.20.
There are other potential problems with having low FDs closed during
exec. For example it used to be possible to subvert setuid versions
of ping to send out arbitrary data from a raw socket by exploting this
problem.
For extra safety I would suggest opening "/" for input instead of
"/dev/null".
The only programs that would be adversely affected by this change from
"/dev/null" to "/" are programs that would have tried to read from a
closed file descriptor in any case. The rationale for doing things
this way is that in some chroot() environments, "/dev/null" could be
absent, while "/" can't ever be absent (I seem to remember that it
could be absent in Unix V6, but we don't support that for coreutils).
Regards,
James Youngman.