public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Stefan Boresch <stefan@mdy.univie.ac.at>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] bind-9.1.3-r7
Date: Fri, 15 Mar 2002 13:45:00 +0100	[thread overview]
Message-ID: <20020315124500.GG13662@mdy.univie.ac.at> (raw)
In-Reply-To: <Pine.LNX.4.43.0203151116360.24180-100000@kubstu.kub.nl>

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



      reply	other threads:[~2002-03-15 12:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-07  7:59 [gentoo-dev] bind-9.1.3-r7 Todd Punderson
2002-03-15 10:30 ` gentoo-user
2002-03-15 12:45   ` Stefan Boresch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020315124500.GG13662@mdy.univie.ac.at \
    --to=stefan@mdy.univie.ac.at \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox