From owner-freebsd-security Tue May 16 4:48: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from srh0902.urh.uiuc.edu (srh0902.urh.uiuc.edu [130.126.76.224]) by hub.freebsd.org (Postfix) with SMTP id 39C7737B95A for ; Tue, 16 May 2000 04:48:06 -0700 (PDT) (envelope-from ftobin@uiuc.edu) Received: (qmail 21818 invoked by uid 1000); 16 May 2000 11:48:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 May 2000 11:48:05 -0000 Date: Tue, 16 May 2000 06:48:05 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0902.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: pid file for named Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One often wishes to run daemons such as named under other users, e.g., bind:bind. In order to allow bind to write out zones and associated fun stuff correctly, one then does a chmod -R bind:bind /etc/named However, the pid file, /var/run/named.pid, which named tries to write out one cannot give the proper permissions for, because it resides in a root-owned directory /var/run. Granted, named writes out this file before it drops privileges, and doesn't need to re-write this file when it reloads, even though it tries and complains about not being able to because it has dropped privileges. However, at some time we (FreeBSD community) may wish to have a named setup where the we don't have to rely on named dropping its privileges; the better solution of course is to only start it with the proper privileges, and the low-port allocation bit will be handled by a proper capabilities/ACL setup. If we ever move to this setup, where named is started with the lowered-permissions already, it will not be able to write out its pid file correctly. Hence, my suggestion is that the PID file for named be /var/run/named/named.pid. Having this be the location will solve two problems, the minor one of named complaining about not being able to write out it's pid file when reloading, and the future-possibility problem if named is started with lowered-privs, instead of having it drop privs. If we fix it now we don't have to worry about it later. Note that this change we may wish to have changed for many of our daemons (I already put apache's runtime stuff in /var/run/apache/, even though it runs as root). -- Frank Tobin http://www.uiuc.edu/~ftobin/ "To learn what is good and what is to be valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message