[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NMU'ing for wishlist bugs? (aka: intent to NMU bind9)

Stephen Frost <sfrost@snowman.net> [2002-09-16 14:11:31 -0400]:
> * Javier Fern?ndez-Sanguino Pe?a (jfs@dat.etsit.upm.es) wrote:
> > I might be a little stubborn... but what happens if:
> > 
> > 1.- user installs bind
> > (the 'named' user gets created)
> > 2.- user configures the name server and sets the zone information in
> > common dir, for example /var/named/
> Now hang on a second here.  You think the master zone files are going to
> be owned by the named user?  That's a bad assumption to begin with, they
> should be owned by root (as they are on my system...).

Agreed. <Alarm Bells!> The entire purpose of running named as special
account is to restrict any access to the filesystem if the daemon is
cracked.  Therefore assuming a 'named' user as is typical for running
named non-root, then zero configuration files, absolutely none, should
ever be owned by the 'named' user.  All configuration files should be
owned by 'root' to keep them safe from damage in the case of a
successful attack against the daemon.

Files that the daemon writes will need to be in a 'named' writable
directory.  Those are the pid file and any DNS zones that are slaved
by the local server.  But those would be recreated fresh every time
the daemon is restarted.  In the case of a slave when the serial
number is updated.  If you are making major changes you should kill,
clean, then restart.  But if you are running a DNS secondary then you
are expected to know a little more.

> So, really, all we're talking about here are cache files which
> should be recreated when you update anyway.  I should have realized
> the folly of the original proposal earlier.
> As for some directory where the master zone files are stored...  There's
> stuff in the debian developer's manual on how to handle that kind of
> situation, as I recall.   The directory and files should be owned by
> root though, not named.



Attachment: pgpAlN6H5BLfq.pgp
Description: PGP signature

Reply to: