From owner-freebsd-questions@FreeBSD.ORG Wed Apr 30 19:06:37 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 070D4EDC for ; Wed, 30 Apr 2014 19:06:37 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id D3635185B for ; Wed, 30 Apr 2014 19:06:36 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id 3483133C25; Wed, 30 Apr 2014 15:00:58 -0400 (EDT) From: Lowell Gilbert To: Charles Swiger Subject: Re: system(3) && open file descriptors References: <20140429184307.GA1114@tiny-r255948> <71BBF914-AA3A-4701-8395-0A5C49474948@mac.com> <20140430044151.GA1668@La-Habana> Date: Wed, 30 Apr 2014 15:00:58 -0400 In-Reply-To: (Charles Swiger's message of "Wed, 30 Apr 2014 10:49:44 -0700") Message-ID: <44y4ymd4lx.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Matthias Apitz , freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:06:37 -0000 Charles Swiger writes: > On Apr 29, 2014, at 9:41 PM, Matthias Apitz 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 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. My reading of the POSIX spec leads me to say that it isn't allowed to. This is probably an oversight on the part of the standards folks, because there's little useful application for the child process to use open file descriptors beyond stdin/out/error. > 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. One would think. > 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. I definitely wouldn't be comfortable with it if it violates the standard (I'm not sufficiently confident in my reading of the relevant language to flatly declare that it does). I *can* dream up scenarios that would use such an effect, but I've never seen any in the wild; people do the fork() and execl() by hand. > So improving the manpage strikes me as a fine idea.... No question.