Re: [nmh-workers] closefds() _before_ fork?

[Ken Hornstein]

>Ken Hornstein <address@hidden> writes:
>> I realize that dup2() clears the FD_CLOEXEC flag on the new file
>> descriptor so the "normal" case of an opened file being dup2() down to 0
>> would work correctly, but the wrinkle is that it does NOT if the old and
>> new file descriptor are the same.  That is admittedly unlikely, but it
>> could happen in a few cases so I'd like to be as robust as possible.
>
>But is that really an issue?  It'd only occur if you're passing down
>your own stdin, which presumably you inherited without FD_CLOEXEC.

Weeelll ... here's a hypothetical issue, which I could see happening.

- Something gets invoked with stdin closed; note that many of these programs
  that this is an issue with are run unattended, e.g. slocal(1).  So it's
  possible (but unlikely) that they could be run without a valid stdin.

- A file is opened and gets assigned the lowest valid file descriptor,
  which in this case is 0.  Because of the "new" policy (which we haven't
  implemented yet), we mark it with FD_CLOEXEC.

- We want to pass this file descriptor to the stdin of a subprocess.  So
  we end up calling dup2(0, 0).  We would normally expect FD_CLOEXEC to be
  cleared, but in this specific case it is not.  So when the child process
  is exec()d, it's standard input is closed (and presumably doesn't work
  properly).

If there's one thing I've learned from nmh, it is "expect weird stuff to
happen" :-)

--Ken