bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nohup definition should be changed


From: James Youngman
Subject: Re: nohup definition should be changed
Date: Thu, 26 May 2005 14:35:16 +0100
User-agent: Mutt/1.3.28i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]