Re: nohup definition should be changed

[Nick Maclaren]

> 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:  address@hidden
Tel.:  +44 1223 334761    Fax:  +44 1223 334679