From owner-svn-src-head@FreeBSD.ORG Tue Jan 24 15:34:43 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 B79C21065673; Tue, 24 Jan 2012 15:34:43 +0000 (UTC) (envelope-from guy.helmer@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 788F38FC13; Tue, 24 Jan 2012 15:34:43 +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 q0OFYOsG049362; Tue, 24 Jan 2012 09:34:24 -0600 (CST) (envelope-from guy.helmer@palisadesystems.com) Received: from guysmbp.dyn.palisadesys.com (GuysMBP.dyn.palisadesys.com [172.16.2.90]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id q0OFYGJE056803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 09:34:17 -0600 (CST) (envelope-from guy.helmer@palisadesystems.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com q0OFYGJE056803 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=palisadesystems.com; s=mail; t=1327419257; bh=+Z88rYjFimCHLRDeWbNgBvqXk/BnCUUmiq+5Ky6CfTI=; l=128; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mIGvB9fbDiTkL62qowEAYAd7z4WeqS/f3zKlWc2CzVGVLHQ8Tg0oK8zCOXByyHH3e klJ7MlnWo0X8NEwzzjxEEUILKieeI8m33Dv4c3NTzfyoa2dtKw/QzWF8umZXopPgxz u4rECRc7mktKI3cvwU8X8Au6aCtPBaOVb+isuV4k= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Guy Helmer In-Reply-To: <4F078EC4.2090802@FreeBSD.org> Date: Tue, 24 Jan 2012 09:34:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <124C24A6-1E2A-4D30-9ED5-7F717C2E2A4D@palisadesystems.com> References: <201201052248.q05MmaZk059871@svn.freebsd.org> <4F066340.9010507@FreeBSD.org> <4F078EC4.2090802@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Tue, 24 Jan 2012 09:34:17 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: q0OFYGJE056803 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.628, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, RP_8BIT 1.27) X-Palisade-MailScanner-From: guy.helmer@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 Subject: Re: svn commit: r229667 - 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: Tue, 24 Jan 2012 15:34:43 -0000 On Jan 6, 2012, at 6:16 PM, Doug Barton wrote: > On 01/06/2012 08:18, Guy Helmer wrote: >> On Jan 5, 2012, at 8:58 PM, Doug Barton wrote: >>=20 >>> On 01/05/2012 14:48, Guy Helmer wrote: >>>> Allow daemon(8) to run pidfile_open() before relenquishing >>>> privileges so pid files can be written in /var/run when started >>>> as root. >>>=20 >>> I'm not sure how useful this is since when daemon is exiting it >>> won't be able to remove the pid file (unless I'm missing >>> something). >>>=20 >>> Isn't it better to pre-create the pid file with the proper >>> permissions for the unprivileged user? >>>=20 >>=20 >> Would it be OK for daemon to hang around and wait for the child >> process to exit, then remove the pid file? >=20 > Without having given it any kind of careful thought, that sounds Ok = ... > but I don't understand how daemon could remove a pid file written as > root after it's already dropped privileges. (IOW that's the same = problem > I was bringing up.) >=20 >> The only other alternative I see would be to create a subdirectory >> that is writable by the user so the child can create and delete the >> pid file. >=20 > That's functionally equivalent to pre-creating the pid file with the > right permissions, so it would be Ok. Various ports use each of these > approaches. I'm generally in favor of using the pid file only solution > since rc.d/cleanvar will clean all that stuff up at boot, and it's > preferable to not leave stale directories around for stuff that is no > longer running and/or installed. Having thought about it for a while, I plan to revert the change to = daemon.c that was suggested in the PR, and instead add this note to the = man page: Index: daemon.8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- daemon.8 (revision 230510) +++ daemon.8 (working copy) @@ -59,6 +59,10 @@ using the .Xr pidfile 3 functionality. +If the +.Fl u +option is used, the directory to contain the pidfile must be writable +by the specified user. Note, that the file will be created shortly before the process is actually executed, and will remain after the process exits (although it will be removed if the execution fails). Guy -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure.