From owner-svn-src-head@FreeBSD.ORG Tue Jan 24 21:45:32 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0145E106564A; Tue, 24 Jan 2012 21:45:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D14D214DE50; Tue, 24 Jan 2012 21:45:31 +0000 (UTC) Message-ID: <4F1F267B.4080005@FreeBSD.org> Date: Tue, 24 Jan 2012 13:45:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Guy Helmer References: <201201052248.q05MmaZk059871@svn.freebsd.org> <4F066340.9010507@FreeBSD.org> <4F078EC4.2090802@FreeBSD.org> <124C24A6-1E2A-4D30-9ED5-7F717C2E2A4D@palisadesystems.com> In-Reply-To: <124C24A6-1E2A-4D30-9ED5-7F717C2E2A4D@palisadesystems.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 21:45:32 -0000 On 01/24/2012 07:34, Guy Helmer wrote: > 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: >>> >>>> 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. >>>> >>>> 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). >>>> >>>> Isn't it better to pre-create the pid file with the proper >>>> permissions for the unprivileged user? >>>> >>> >>> Would it be OK for daemon to hang around and wait for the child >>> process to exit, then remove the pid file? >> >> 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.) >> >>> 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. >> >> 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: I think that reverting it is a good idea. I would add something to the effect of what's below. I continue to maintain that pre-creating the file is preferable to using directories since we'd like to avoid leaving no-longer-relevant directories around if the thing is not in use any longer. Doug > Index: daemon.8 > =================================================================== > --- 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 pidfile must be pre-created with the proper > +permissions, or 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. > -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/