From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] xl: close nullfd after dup2'ing it to stdin Date: Tue, 16 Feb 2016 21:54:22 +0000 Message-ID: <1455659662.15441.61.camel@citrix.com> References: <1455622545-22269-1-git-send-email-ian.campbell@citrix.com> <22211.24628.386971.873827@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22211.24628.386971.873827@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: andrew.cooper3@citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, 2016-02-16 at 17:45 +0000, Ian Jackson wrote: > Ian Campbell writes ("[PATCH] xl: close nullfd after dup2'ing it to > stdin"): > > Taking care not to do so if nullfd happens (somehow) to have the > same > > fd number as stdin/out/err. > > I think that can only happen if the program (the process) has a > serious problem: ie, fd 0 1 or 2 would have to be closed. Yes, that was my thought and what I wanted to guard against. > If that happens many other things can go badly wrong. Indeed. I've seen this happen in other scenarios with non-C programs forking and execing stuff with stdio fds closed. > If this is causing Coverity to complain I would suggest adding > assert(nullfd >= 3); > assert(logfile >= 3); > instead. Coverity wasn't complaining about this particular aspect, it was only complaining about the leak of nullfd, avoiding stdin/out/err was just me being belt and braces about the possibility of nullfd being one of the stdio fds. I'm happy with the assert approach too. Ian