[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/53652: Change permission of namedb directory
The following reply was made to PR bin/53652; it has been noted by GNATS.
From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas), gnats-bugs%NetBSD.org@localhost
Subject: Re: bin/53652: Change permission of namedb directory
Date: Wed, 10 Oct 2018 21:04:32 -0700
On Oct 10, 11:12am, Christos Zoulas wrote:
} On Oct 6, 4:15pm, taca%back-street.net@localhost (taca%back-street.net@localhost) wrote:
} Yes, the secroots issue correct; as well as:
} The pathname of the file the server dumps the database to when instructed to do so with rndc dumpdb. If not specified, the default is named_dump.db.
} The pathname of the file the server writes memory usage statistics to on exit. If not specified, the default is named.memstats.
} The pathname of the file the server dumps the queries that are currently recursing when instructed to do so with rndc recursing. If not specified, the default is named.recursing.
} The pathname of the file the server appends statistics to when instructed to do so using rndc stats. If not specified, the default is named.stats in the server's current directory. The format of the file is described in the section called "The Statistics File".
} The pathname of the file the server dumps security roots to when instructed to do so with rndc secroots. If not specified, the default is named.secroots.
} So I guess we can either revert the "nta" file change and make /etc/namedb
} writable by the daemon, or we can double down and create a "stats" or "status"
} or "logs" directory in /etc/named and default all of those files to go there.
} It sounds neater to do that, but it is not desirable from a compatibility POV.
} I think we should go with the first option (revert/make writable). Opinions?
I seriously think we should go with the second option. Having
/etc/namedb writable by daemon of a master server leaves it open
to complete corruption of the zone files and possibly configuration
files if there is a compromise of the server. I recognise that
this may be a nuisance on a server that mainly server slave zones
since it means that you can't just add a zone to the config file.
This kinda leads to the idea that it should be an option.
}-- End of excerpt from Christos Zoulas
Main Index |
Thread Index |