Ken Hornstein <kenh@pobox.com> 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
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers