Re: nohup definition should be changed
I agree about redirecting rather than closing, which is what I put in the original posted code snippet. But redirection input from / seems strange albeit legal. I think nohup would most likely be run from the command line, and in that environment /dev/null almost certainly will exist. If not having nohup fail with an appropriate error message is reasonable as the chroot/jail/zone environment *should* have /dev/null, right? This hack is getting messier and messier. PLEASE rethink. A) This will end up producing semantic differences between two identical file descriptions (e.g. stdin on entry and a dup of it). B) No, '/' need NOT be present, let alone accessible. It is perfectly reasonable to run a program in a chroot where it is blocked from ANY file access. For example: Running a process that is intended to drive an attached, non-Unix, non-programmable device. Running a process that does something unspeakable to the hardware, asynchronously. Running a process that has so much privilege that it breaks the system's file security mechanisms. In all of those cases, you want to give it descriptors X, Y and Z, and not allow it ANY further access to the system. Implementors need no encouragement to produce damn-fool programs that require (say) a controlling terminal, an X display or a fancy TERM setting for non-interactive or line-mode use. GNU ex and more are dire in that respect, and there are worse examples. But enshrining that dementia in POSIX is even worse. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Nick Maclaren [EMAIL PROTECTED] writes: Implementors need no encouragement to produce damn-fool programs that require (say) a controlling terminal, an X display or a fancy TERM setting for non-interactive or line-mode use But enshrining that dementia in POSIX is even worse. I suspect we may be straying from the original point (namely, the question whether POSIX should be changed to allow nohup to close a tty stdin) and are starting to worry about implementation details. If an implementation guarantees that / or /dev/none exists with certain properties, the nohup implementer can take advantage of that fact -- that's outside the scope of POSIX. But this leaves the question whether POSIX should allow nohup to close a stdin tty. By the way, I assume that it's OK for nohup (or for any utility) to open (say) /dev/null a few times. That is, I assume there's no prohibition by POSIX on implementations of standard utilities opening files (and thereby consuming a few file descriptors). Hence, if nohup is allowed to close a stdin tty, it's also allowed to open stdin and point it at /dev/null, or at /, or whereever it likes. If this assumption isn't correct, I suppose the original proposal http://www.opengroup.org/austin/mailarchives/ag/msg08344.html needs rewording. '/' need NOT be present, let alone accessible. '/' must be present on all conforming POSIX systems; it is required by XBD 10.1 The following directories shall exist on conforming systems. '/dev/null' must also be present, along with a few other files. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
I suspect we may be straying from the original point (namely, the question whether POSIX should be changed to allow nohup to close a tty stdin) and are starting to worry about implementation details. ... No, not at all. The question is whether it is a good idea to treat that particular implementation detail as special, and specify it explicitly. In particular, why shouldn't the same wording be used for (a) dups of stdin/stdout/stderr, (b) other terminals, (c) the controlling terminal (if any) and (d) the process group? In particular, I pointed out that some 'conforming' versions of nohup do NOT do what the description says (i.e. invoke a utility immune to hangups or At the time the named utility is invoked, the SIGHUP signal shall be set to be ignored.) because they MERELY fiddle the process mask. If the utility traps SIGHUP and then execs to a process that doesn't, a SIGHUP to the process group will kill the utility. Is this a breach of POSIX? If so, why? If not, what does that wording mean, if anything? '/' must be present on all conforming POSIX systems; it is required by XBD 10.1 The following directories shall exist on conforming systems. '/dev/null' must also be present, along with a few other files. The question isn't whether / is present in the system as a whole, but whether it is visible to the process. I know that POSIX doesn't specify chroot, but I don't think that it is forbidden. Why should POSIX require a chroot tree to have a ./dev/null? And, if it doesn't, why shouldn't an implementation have a delroot function and command? Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Nick Maclaren [EMAIL PROTECTED] writes: why shouldn't the same wording be used for (a) dups of stdin/stdout/stderr, (b) other terminals, (c) the controlling terminal (if any) and (d) the process group? These might all be nice things to add, but I don't know of any practical solution to all these problems in a POSIX implementation, whereas we do have a simple practical solution to the all-too-common case of the nohup + ssh + tty-stdin problem. Once someone has implemented a more-general solution we can worry about its effect on the POSIX standard; in the meantime let's do what we can do easily for this common case. In particular, I pointed out that some 'conforming' versions of nohup do NOT do what the description says (i.e. invoke a utility immune to hangups or At the time the named utility is invoked, the SIGHUP signal shall be set to be ignored.) because they MERELY fiddle the process mask. If the utility traps SIGHUP and then execs to a process that doesn't, a SIGHUP to the process group will kill the utility. Is this a breach of POSIX? Yes, because POSIX says that nohup must set the SIGHUP signal to be ignored. This is clear to me at least. If it's not clear to your supplier I suppose you could file a formal interpretation request. I know that POSIX doesn't specify chroot, but I don't think that it is forbidden. Yes, the implementation can support chroot, but if an application uses chroot it's outside the realm of what POSIX specifies, so it's not an issue here. (And again, we're straying away from the question of nohup into an implementation detail.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
James Youngman wrote:
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:
[EMAIL PROTECTED] 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.19r2=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.
I agree about redirecting rather than closing, which is what I put
in the original posted code snippet. But redirection input from /
seems strange albeit legal. I think nohup would most likely be run from
the command line, and in that environment /dev/null almost certainly
will exist. If not having nohup fail with an appropriate error
message is reasonable as the chroot/jail/zone environment *should*
have /dev/null, right?
-Wayne Pollock
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Your message about nohup's problems had me nodding in agreement, as similar
problems have happened to me. Are there any objections to my
installing this patch into GNU coreutils?
2005-05-12 Paul Eggert [EMAIL PROTECTED]
* NEWS: nohup now closes stdin if it is a terminal, unless
POSIXLY_CORRECT is set. This fixes a glitch noted by Wayne Pollock in
https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-group-lid=8341.
* doc/coreutils.texi (nohup invocation): Document this.
* src/nohup.c (main): Implement this.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.287
diff -p -u -r1.287 NEWS
--- NEWS8 May 2005 16:52:43 - 1.287
+++ NEWS12 May 2005 08:51:40 -
@@ -139,6 +139,9 @@ GNU coreutils NEWS
join now supports a NUL field separator, e.g., join -t '\0'.
join now detects and reports incompatible options, e.g., join -t x -t y,
+ nohup now closes stdin if it is a terminal, unless POSIXLY_CORRECT is set.
+ This prevents the command from tying up an OpenSSH session after you logout.
+
stat -f -c %S outputs the fundamental block size (used for block counts).
stat -f's default output format has been changed to output this size as well.
stat -f recognizes file systems of type XFS and JFS
Index: doc/coreutils.texi
===
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.256
diff -p -u -r1.256 coreutils.texi
--- doc/coreutils.texi 6 May 2005 17:57:35 - 1.256
+++ doc/coreutils.texi 12 May 2005 08:51:41 -
@@ -12568,6 +12568,12 @@ regardless of the current umask settings
If standard error is a terminal, it is redirected to the same file
descriptor as the (possibly-redirected) standard output.
[EMAIL PROTECTED] 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.
+
@command{nohup} does not automatically put the command it runs in the
background; you must do that explicitly, by ending the command line
with an @samp{}. Also, @command{nohup} does not change the
Index: src/nohup.c
===
RCS file: /fetish/cu/src/nohup.c,v
retrieving revision 1.23
diff -p -u -r1.23 nohup.c
--- src/nohup.c 23 Apr 2005 05:57:33 - 1.23
+++ src/nohup.c 12 May 2005 08:51:41 -
@@ -96,6 +96,12 @@ main (int argc, char **argv)
usage (NOHUP_FAILURE);
}
+ /* If standard input is a tty, close it. POSIX requires nohup to
+ leave standard input alone, but that's less useful in practice as
+ it causes a nohup foo exit session to hang with OpenSSH. */
+ if (!getenv (POSIXLY_CORRECT) isatty (STDIN_FILENO))
+close (STDIN_FILENO);
+
/* If standard output is a tty, redirect it (appending) to a file.
First try nohup.out, then $HOME/nohup.out. */
if (isatty (STDOUT_FILENO))
@@ -139,7 +145,7 @@ main (int argc, char **argv)
free (in_home);
}
- /* If stderr is on a tty, redirect it to stdout. */
+ /* If standard error is a tty, redirect it to stdout. */
if (isatty (STDERR_FILENO))
{
/* Save a copy of stderr before redirecting, so we can use the original
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Jim Meyering [EMAIL PROTECTED] writes: Paul Eggert [EMAIL PROTECTED] wrote: Are there any objections to my installing this patch into GNU coreutils? Fine by me. OK, I installed it. Thanks for the quick review! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Paul Eggert [EMAIL PROTECTED] wrote: Your message about nohup's problems had me nodding in agreement, as similar problems have happened to me. Are there any objections to my installing this patch into GNU coreutils? 2005-05-12 Paul Eggert [EMAIL PROTECTED] * NEWS: nohup now closes stdin if it is a terminal, unless POSIXLY_CORRECT is set. This fixes a glitch noted by Wayne Pollock in https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-group-lid=8341. * doc/coreutils.texi (nohup invocation): Document this. * src/nohup.c (main): Implement this. Fine by me. Thanks to both of you. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
