Maintained by: NLnet Labs

[Unbound-users] unbound 1.4.16 release

Juergen Daubert
Thu Feb 2 19:49:12 CET 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 
necessary. 
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. 


best regards
Juergen