This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: navid Rahimi <rahimi dot nv at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Sep 2015 21:01:29 +0000
- Subject: Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- Authentication-results: sourceware.org; auth=none
- References: <55F19819 dot 3010601 at gmail dot com> <20150911182249 dot GD640 at vapier> <CAOUBrm3me5L+9XxRz5-a+vGURKzD4Z9DxJWfx2GpSjL6x8ywhw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1509111955160 dot 14056 at digraph dot polyomino dot org dot uk> <CAOUBrm3Y9F6SeQFpYCuB-_s9Bbe8Vkaf5gkTMBBbgncOhvJ1wQ at mail dot gmail dot com>
On Sat, 12 Sep 2015, navid Rahimi wrote:
> On Sat, Sep 12, 2015 at 12:28 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Sat, 12 Sep 2015, navid Rahimi wrote:
> > You can't assume that pipe2 is supported unless __ASSUME_PIPE2 is defined.
> > It might be an ENOSYS stub, or it might be unsupported at runtime because
> > the kernel isn't recent enough. In either case, an ENOSYS error from
> > pipe2 must not result in such an error from posix_spawn.
> > Joseph S. Myers
> > joseph@codesourcery.com
>
> Freebsd uses vfork (and its blocking nature for parent process) for
> implementation of posix_spawn , but I have found cert article about
> not using vfork
>
> https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=1703954
>
> pipes was more reliable in overall sight (in my opinion, because I
> have seen so much people complaining about vfork) , but I can
Well, you can use pipes provided you have a fallback from pipe2 to pipe in
the case where __ASSUME_PIPE2 is not defined and pipe2 fails with ENOSYS
at runtime. (There would be a race if another thread forks and execs
between the calls to pipe and fcntl FD_CLOEXEC, but that's unavoidable in
the absence of pipe2.)
--
Joseph S. Myers
joseph@codesourcery.com