[Unbound-users] unbound 1.4.16 release
jue at jue.li
Thu Feb 2 18:49:12 UTC 2012
On Thu, Feb 02, 2012 at 04:02:38PM +0100, Juergen Daubert wrote:
> On Thu, Feb 02, 2012 at 02:47:41PM +0100, W.C.A. Wijngaards wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Hi Juergen,
> > On 02/02/2012 01:49 PM, Juergen Daubert wrote:
> > >> Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:
> > >
> > > thanks for the new release, however I think we have one regression
> > > wrt ownership of the autotrust file, default
> > > /etc/unbound/root.key.
> > >
> > > This file must be owned by the user unbound is running as, e.g.
> > > the user unbound. Starting with version 1.4.15 unbound-anchor
> > > resets the ownership to the user running unbound-anchor, which is
> > > normaly root.
> > That is very inconvenient. This is because it writes to a temp first,
> > then moves it over the first.
> It should be possible for unbound-anchor to preserve the ownership and
> other file attributes of the old file and set the new created to the same?
> If not we have a real problem, because after each call to unbound-anchor
> we have reset the autotrust file to the correct attributes.
After a second look I've to say that I was wrong and all of this is not
Looks like that unbound changes the owner of the autotrust file just before
it gives up root privileges. So putting root.key in a directory, writable
by the user unbound is running as, works.
> > > Because of that the running unbound cannot longer update the key
> > > file, which leasds to a error message:
> > >
> > > Feb 2 12:33:43 tor unbound: [19568:0] error: could not open
> > > autotrust file for writing, root.key.19568-0: Permission denied
> > No, it is not allowed to create a new file in the directory. It wants
> > to create a tempfile to write to, when that has worked, it'll mv the
> > new over the old. So that failures during the write leave you with a
> > bootable system.
> > That part is working: this error may be inconvenient, but the system
> > still boots.
> > I guess you have to chown unbound /my/keydir
> > or chgrp unbound /my/keydir
> > This sort of solution becomes system specific. What would work for you?
> Giving unbound write permissioons to /etc/unbound, which is the default
> directory for the root.key file, is not a good idea IMO.
> I'd prefer to put the autotrust anchor-file in a subdirectory, probably
> /etc/unbound/anchor, and chown that directory to the user unbound is
> running as. So we have a full path of /etc/unbound/anchor/root.key to
> the autotrust file.
> Of course I'll use what you decide to be the new default for unbound.
> But keep in mind that this will only work at all if the above point
> is solved and unbound-anchor preserves the owner of the file.
Not correct, see above.
More information about the Unbound-users