From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 16:32:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B3616A4CE for ; Wed, 29 Oct 2003 16:32:02 -0800 (PST) Received: from smtp.sw.oz.au (alt.aurema.com [203.217.18.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FAC43FEA for ; Wed, 29 Oct 2003 16:32:00 -0800 (PST) (envelope-from vance@aurema.com) Received: from smtp.sw.oz.au (localhost [127.0.0.1]) by smtp.sw.oz.au with ESMTP id h9U0VsQg029737; Thu, 30 Oct 2003 11:31:57 +1100 (EST) Received: (from vance@localhost) by smtp.sw.oz.au id h9U0VrgD029735; Thu, 30 Oct 2003 11:31:53 +1100 (EST) Date: Thu, 30 Oct 2003 11:31:53 +1100 From: Christopher Vance To: "Dan Langille" Message-ID: <20031030003153.GC16553@aurema.com> References: <3F9CF3F6.8307.ABC1250@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3F9CF3F6.8307.ABC1250@localhost> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 00:32:02 -0000 On Mon, Oct 27, 2003 at 10:31:18AM -0500, Dan Langille wrote: >If a process starts up and does a setuid, should it be writing the >PID file before or after the setuid? > >Two methods exists AFAIK: > >1 - write your PID immediately, and the file is chown root:wheel >2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ > is chown myapp:myapp > >Of the two, I think #1 is cleaner as it does not require another >directory with special permissions. You can already mark a fd 'close on exec'. May I suggest a different feature: the ability to mark an open file (not just its fd) 'remove on close', with permission checked at mark time rather than close time (this status forgotten if not permitted when set) and the unlink actually done at close time only if the file has exactly one link and one open file instance at that time. That way your server can start as root open file to write/update downgrade/reopen file to readonly mark remove on close setuid non-root Or you could call it a future unlink. I'm sure there are holes in it, and I won't claim to have tried it, ... -- Christopher Vance