[gentoo-dev] bind-9.1.3-r7

[gentoo-dev] bind-9.1.3-r7

[Todd Punderson]

I did a update --world tonight and I also ran into this. It's probably 
destined for bugzilla, but I wanted to ask first.

After updating to bind-9.1.3-r7 I had a problem getting it to run. I
determined the problem to be the following. The named startup script
executes this: start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -n 1

Since named switches to uid 'named' it doesn't have access to write to
/var/run/named.pid  However, I noticed that there is now a
/var/run/named dir that is owned by named.named...This is all well and
good but the named binary doesn't try to write it's pidfile to that
directory and bombs. I looked in the ebuild and the bind documentation
and there is a way to configure it to point to another directory: on the
configure script it needs --localstatedir=/var/run/named instead of
--localstatedir=/var  but this also means that the /etc/init.d/named
script needs to be edited to point to /var/run/named/run/named.pid for
the stop portion of it. Maybe the extra 'run' in there could be edited
out with by modifing the bind source, I didn't dig that far, I just need
it running. :)
        Also /var/bind needs to be owned by named.named in order for the zone
files to be read (since I did an upgrade, this bit me, it may not on a
new install)
-- 
Todd Punderson <todd@doonga.net>

Re: [gentoo-dev] bind-9.1.3-r7

[gentoo-user]

On Thu, 7 Mar 2002, Todd Punderson wrote:

> I did a update --world tonight and I also ran into this. It's probably
> destined for bugzilla, but I wanted to ask first.
>
> After updating to bind-9.1.3-r7 I had a problem getting it to run. I
> determined the problem to be the following. The named startup script
> executes this: start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -n 1
>
> Since named switches to uid 'named' it doesn't have access to write to
> /var/run/named.pid  However, I noticed that there is now a
> /var/run/named dir that is owned by named.named...This is all well and
> good but the named binary doesn't try to write it's pidfile to that
> directory and bombs. I looked in the ebuild and the bind documentation
> and there is a way to configure it to point to another directory: on the
> configure script it needs --localstatedir=/var/run/named instead of
> --localstatedir=/var  but this also means that the /etc/init.d/named
> script needs to be edited to point to /var/run/named/run/named.pid for
> the stop portion of it. Maybe the extra 'run' in there could be edited
> out with by modifing the bind source, I didn't dig that far, I just need
> it running. :)
>         Also /var/bind needs to be owned by named.named in order for the zone
> files to be read (since I did an upgrade, this bit me, it may not on a
> new install)
>

The reason for the change was that bind used to run as root
(inadvertently). It is not safe (or necessary to do so) to run named as
root. For named to run as a different user (that's what the -u option
does) it needs to be able to write it's pid file. This location can be
specified in the config file. This option was included there too. It is
not necessary / not safe for the /var/bind dir to be owned by named. Named
does need to be able to read it though. Only if you want to use dynamic
updates, the files to which you want bind to have access to must be owned
by named. Be very careful with dynamic update though, as it might
compromise your server (and with it possibly your network)

Paul

-- 
  ___
 /~~~\  | Paul de Vrieze
| O-O | | Student of information management and technology
|  _  | | Mail: Paul@devrieze.net
 \___/  | Homepage: http://www.devrieze.net

Re: [gentoo-dev] bind-9.1.3-r7

[Stefan Boresch]

On Fri, Mar 15, 2002 at 11:30:00AM +0100, gentoo-user@devrieze.net wrote:
> On Thu, 7 Mar 2002, Todd Punderson wrote:
> 
> >         Also /var/bind needs to be owned by named.named in order for the zone
> > files to be read (since I did an upgrade, this bit me, it may not on a
> > new install)
> >
> 
> The reason for the change was that bind used to run as root
> (inadvertently). It is not safe (or necessary to do so) to run named as
> root. For named to run as a different user (that's what the -u option
> does) it needs to be able to write it's pid file. This location can be
> specified in the config file. This option was included there too. It is
> not necessary / not safe for the /var/bind dir to be owned by named. Named
> does need to be able to read it though. Only if you want to use dynamic
> updates, the files to which you want bind to have access to must be owned
> by named. Be very careful with dynamic update though, as it might
> compromise your server (and with it possibly your network)
> 

I am by god no bind expert, only forced by local circumstances
to run named.  The issue of the .pid file raised by the original poster
is easily solved by adding a pid-file option to your
/etc/bind/named.conf

options {
        directory "/var/bind";
        pid-file "/var/run/named/named.pid";
};            ^^^^^^^^^^^^^^^^^^^^^^^^^^

However, the ownership of /var/bind is more crucial. I don't think
the problem is with reading if you have standard rw-r--r-- permissions
on zone files; i.e. create files with a 022 umask.
However, a secondary name server (which I need) needs to be able to
write transferred zonefiles somewhere, and with the above directory
option these end up in /var/bind; failing if /var/bind isn't owned
by named.named.  I guess I could put them into /var/bind/sec and 
make this directory writable to named.named.  However, where is
the security problem of /var/bind being owned by named.named in the
first place? Further, it would seem that bind/named drops all privileges
anyways, since starting named without -u fails to write a .pid file
at all (permission denied), which is not consistent with root
permissions.

[Sorry, I come from the bind 8.* world and hope to get by with
using my old config files...]

HTH, and thanks for any clarifications (my gentoo bind9 server should
go into production fairly soon :-)

Stefan