From owner-freebsd-security@FreeBSD.ORG Fri Mar 14 09:38:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54F33AF6 for ; Fri, 14 Mar 2014 09:38:44 +0000 (UTC) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:140:72e1::ac16:e45e]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD26DB6 for ; Fri, 14 Mar 2014 09:38:44 +0000 (UTC) Received: from t420.rlwinm.de (p54BC48D7.dip0.t-ipconnect.de [84.188.72.215]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 6060CB014 for ; Fri, 14 Mar 2014 09:38:43 +0000 (UTC) Message-ID: <5322CE23.6000904@rlwinm.de> Date: Fri, 14 Mar 2014 10:38:43 +0100 From: Crest User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [PATCH] casperd should detach from controlling session References: <53221E54.1030600@delphij.net> In-Reply-To: <53221E54.1030600@delphij.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 09:38:44 -0000 On 13.03.2014 22:08, Xin Li wrote: > Hi, Pawel, > > I have noticed that casperd's child (zygote) would still use > controlling session from parent. This can be observed by running > ps -ax on systems running casperd, where the child have a spurious > console associated. > > The attached patch would fix it. May I commit it against -HEAD? > > By the way, the zygote child also closes file descriptor 4 twice > (harmless; it's either sp[0] or the /dev/null which is closed > before starting zygote_main, or before returning from stdnull(). > Based on the construct of the code, I believe both close() can be > omitted. If this makes sense I'll submit a new patch. Wouldn't this patch break support for external monitoring e.g. by daemontools. By convention a daemontools run script is started with its own process group and execs into the service. If a service tries to unconditionally create its own process group it will fail.