svn commit: r291114 - head/lib/libc/gen

[David Sanderson]

On Fri, Nov 20, 2015 at 7:08 PM, Andrey Chernov <ache at freebsd.org> wrote:

> On 21.11.2015 2:57, Ravi Pokala wrote:
> > There's two different things at play - userland resources and kernel
> resources. Both "FILE *iop" and "struct pid *cur" are userland, while the
> descriptors in "pdes" are kernel. We clean up the descriptors in "pdes" in
> call cases, so we're not leaking kernel resources. You're right that "iop"
> (and "cur", which you didn't mention) appear to be leaked in the child, in
> that they're not explicitly cleaned up. But they get wiped away by the
> _execve(), so it doesn't matter.
>
> See my next reply. I care not about userland resources, but about
> fdopen() ability to set FD_CLOEXEC.


Hi Andrey,

I'll step into this discussion because Ravi submitted this change on my
behalf.

Thank you for pointing out the possibility of fdopen() setting FD_CLOEXEC
on the parent's end of the pipe if the mode string contains an 'e'.  This
is indeed documented on popen(3).

However, note that popen() uses pipe2(pdes, O_CLOEXEC) to create the pipe
-- so both ends of the pipe start out with FD_CLOEXEC set.

If the caller uses popen() with "re" or "we", the fdopen() code will simply
set FD_CLOEXEC on the parent's end of the pipe _again_.  So moving the
fdopen() prior to the fork() doesn't have any net effect on the file
descriptors the child process receives, even in the face of popen() with
"re" or "we".

Does this address your concerns?

Thanks,
David Sanderson