I understand why functions like closefds() are used right before exec(),
but in this case a fair amonut of stuff happens before exec is called,
and it's way before fork() is eventually called as well. The other uses
of closefds() are after a fork() occurs, or right before exec() happens
(see whom.c). Can anyone think of a reason that for this specific
case closefds() should NOT be moved from whatnowbr.c (and send.c) into
sendsbr.c, and just in the child process?
So, following up to myself ....
At least I figured out why closefds() is calld so early. The issue is
the use of the -idanno flag. This flag is used to pass a file descriptor
down for annotations (the called of "post" passes down a file descriptor
number using -idanno, and post writes out the annotation to that descriptor).
So we'd need to either call closefds() before the annotations descriptor
is created, or make it so closefds() can skip one particular descriptor.
But the bigger question is ... why is closefds() used at all?
I see it being used by rcvtty(1), repl(1), send(1), slocal(1), whatnow(1),
and whom(1), 6 instances at all. But by my count there are 28 calls
to exec*(); I didn't match them all up, but it seems like most of the
time we start a child process we don't bother closing all descriptors.
I realize this was a common practice "back in the day", but if any library
functions create a descriptor they should use O_CLOEXEC or FD_CLOEXEC.
And if the concern is nmh leaking file descriptors, we should either fix
that problem or use FD_CLOEXEC ourselves. This isn't just an nmh problem
either ... I see a similar inconsistent use of closefds() in the MH source
code.
I suggest we simply remove closefds() completely. Ralph, David, I saw
your comments ... with my follow-up information, what do you think of
that?
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers