From owner-svn-src-head@FreeBSD.ORG Sat Feb 4 16:49:52 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 685021065672; Sat, 4 Feb 2012 16:49:52 +0000 (UTC) (envelope-from ghelmer@palisadesystems.com) Received: from ps-1-a.compliancesafe.com (ps-1-a.compliancesafe.com [216.81.161.161]) by mx1.freebsd.org (Postfix) with ESMTP id 155948FC13; Sat, 4 Feb 2012 16:49:52 +0000 (UTC) Received: from mail.palisadesystems.com (localhost [127.0.0.1]) by ps-1-a.compliancesafe.com (8.14.4/8.14.3) with ESMTP id q14GU8C6006439; Sat, 4 Feb 2012 10:30:08 -0600 (CST) (envelope-from ghelmer@palisadesystems.com) Received: from [192.168.0.105] (173-20-105-176.client.mchsi.com [173.20.105.176]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id q14GU2sX039755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Feb 2012 10:30:03 -0600 (CST) (envelope-from ghelmer@palisadesystems.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com q14GU2sX039755 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=palisadesystems.com; s=mail; t=1328373004; bh=fkoe7qod3F7agxp9ot7ofzP3aSG4lHkYbgfbsG3Q2dk=; l=128; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pCN6Ch51tTU57fagVhO+MwFW+KJg2GK0xJEATAZsOOfeodrgU6pcpHxpqPqEtN0uX 8BEZO7hR3Zo1+VP0Ovn4QUqzhV7PC/SsVQhabzpOaPOg/Z4RpZgfFpvNDLC5Dpbmzw XgwKdxuWWoLtbDjZ2CJzgaR+01zdtOghL1r6G/os= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Guy Helmer In-Reply-To: <4F2CEB1D.10607@zonov.org> Date: Sat, 4 Feb 2012 10:30:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <27A0A960-F767-4D2C-BF3E-31F73FBF4E28@palisadesystems.com> References: <201202011641.q11Gf0j6095461@svn.freebsd.org> <20120204074201.GA1694@garage.freebsd.pl> <4F2CEB1D.10607@zonov.org> To: Andrey Zonov X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Sat, 04 Feb 2012 10:30:04 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: q14GU2sX039755 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.406, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, RP_8BIT 1.49) X-Palisade-MailScanner-From: ghelmer@palisadesystems.com X-Spam-Status: No X-PacketSure-Scanned: Yes Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: svn commit: r230869 - head/usr.sbin/daemon X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 16:49:52 -0000 On Feb 4, 2012, at 2:23 AM, Andrey Zonov wrote: > On 04.02.2012 11:42, Pawel Jakub Dawidek wrote: >> On Wed, Feb 01, 2012 at 04:41:00PM +0000, Guy Helmer wrote: >>> Author: ghelmer >>> Date: Wed Feb 1 16:40:59 2012 >>> New Revision: 230869 >>> URL: http://svn.freebsd.org/changeset/base/230869 >>>=20 >>> Log: >>> Change the notes about the pidfile to include Doug's preference >>> for pre-creating the pidfile with appropriate owner and = permissions. >>>=20 >>> Requested by dougb >>=20 >> Pre-creating pidfiles? That sounds weird. The common practise is to = turn >> eg. /var/run/.pid into /var/run//pid where = directory >> has appropriate permissions. Pre-creating pidfiles is simply wrong, >> because applications create pidfile on start and unlink it on exit. >> If application has no permission to remove files from /var/run/ it = will >> leave pidfile with stale PID in it, which is bad. Changing = application >> to truncate pidfile on exit instead of unlinking it also is a bad = idea >> especially because there is working solution - pid directory. >>=20 >=20 > Hi, >=20 > There's even worse problem - kernel closes pidfile in execvp() because = of FD_CLOEXEC flag is set and daemon doesn't hold lock on pidfile. >=20 > I reported about that earlier, but was ignored. I don't understand your concern about this -- the daemon(8) program = exists to start a program that does not manage its own user authority or = pid file, and it is inappropriate to leak the open pidfile descriptor to = the program that daemon(8) execs. Guy= -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure.