Date: Wed, 30 Apr 2014 10:49:44 -0700 From: Charles Swiger <cswiger@mac.com> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-questions@freebsd.org Subject: Re: system(3) && open file descriptors Message-ID: <C3B0FF38-4B1F-4C37-92F4-62935B894631@mac.com> In-Reply-To: <20140430044151.GA1668@La-Habana> References: <20140429184307.GA1114@tiny-r255948> <71BBF914-AA3A-4701-8395-0A5C49474948@mac.com> <20140430044151.GA1668@La-Habana>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 29, 2014, at 9:41 PM, Matthias Apitz <guru@unixarea.de> wrote: > El d=EDa Tuesday, April 29, 2014 a las 02:41:22PM -0700, Charles = Swiger escribi=F3: >> Hi-- >>=20 >> On Apr 29, 2014, at 11:43 AM, Matthias Apitz <guru@unixarea.de> = wrote: >>> It seems that the proc started by the C library call system(3), as >>> /bin/sh -c string >>> owns the same set of open file descriptors as its calling proc. Is = this >>> somewhere documented as a feature? 'man system" does not say = anything >>> about, while 'man fork' does. >>=20 >> At least my version of system(3) says that it invokes fork(2) and = checks >> the exit status of the shell via waitpid(2). That plus listing = fork(2) >> in SEE ALSO section seems to be enough of a pointer to the detailed >> behavior.... >=20 > Hi, > Ofc it must use fork(2), but it *could* as well close all fd before > execv(2). IMHO it should do this for all fd > 2, at least the man page > should mention the fact that it does not. Ah, I see your point. Yes, I suspect that folks who intend to pass FDs to children would be = more disciplined about using FD_CLOEXEC and/or doing their own FD cleanup = while calling fork/exec directly. Folks who call system() probably aren't expecting their FDs to be = passed, but I'm not sure it would be safe to change the current behavior by closing FDs for them when it did not do so before. So improving the manpage strikes me as a fine idea.... Regards, --=20 -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3B0FF38-4B1F-4C37-92F4-62935B894631>