unbound icon indicating copy to clipboard operation
unbound copied to clipboard

fatal error: could not open autotrust file for writing, /root.key.10018-0-16059b0: Permission denied

Open minfrin opened this issue 1 year ago • 2 comments

Describe the bug Startup of unbound fails, unbound logs the following:

Nov 9 11:49:36 rocky9 unbound[10018]: [10018:0] fatal error: could not open autotrust file for writing, /root.key.10018-0-16059b0: Permission denied

To reproduce Steps to reproduce the behavior:

  1. Download release v1.22.0 on unbound, ./configure; make; make install
  2. Run unbound-anchor
  3. Set config to auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
  4. Launch unbound as follows: /usr/local/sbin/unbound -d -c /usr/local/etc/unbound/unbound.conf

Expected behavior Unbound server runs in the foreground.

System:

  • Unbound version: 1.22.0
  • OS: Rocky9
  • unbound -V output:

[root@rocky9 unbound]# /usr/local/sbin/unbound -V Version 1.22.0

Configure line: Linked libs: mini-event internal (it uses select), OpenSSL 3.0.7 1 Nov 2022 Linked modules: dns64 respip validator iterator

BSD licensed, see LICENSE in source package for details. Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

Additional information It looks like the location of the temporary file and the auto-trust-anchor-file are different somehow.

minfrin avatar Nov 09 '24 11:11 minfrin

Running through strace, we see getpid() in an infinite loop.

getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035
getpid()                                = 10035

Eventually we see the following:

getpid()                                = 10035
getpid()                                = 10035
openat(AT_FDCWD, "/root.key.10035-0-d439b0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
getpid()                                = 10035
sendto(7, "<26>Nov  9 12:00:56 unbound: [10"..., 138, MSG_NOSIGNAL, NULL, 0) = 138
exit_group(1)                           = ?
+++ exited with 1 +++

minfrin avatar Nov 09 '24 12:11 minfrin

I believe that the list of getpid() calls could be that unbound is logging a number of messages. Each has the pid of unbound and the timestamp, and that call is maybe what is shown in the list. It means there could be logs, in syslog, or unbound.log about what happened. It would probably show the same error, about the file.

The root.key file with a temporary name is created so that unbound is fully sure that it can write the file completely, before it renames the file and replaces the active root.key file. To create that file, the directory that it is written to must allow unbound to create content, that means username and permission flags. The default mkdir of /usr/local/etc/unbound is likely owned by root, and without permissions for the unbound user to make the new file in there. Perhaps what is needed is chown unbound /usr/local/etc/unbound or perhaps also chmod 755 /usr/local/etc/unbound (that enables write permission and access permission for the user to the directory).

Is there perhaps a location in the man page that was looked at where a note can be added to help users find out about the directory ownership and permissions needed? Some people install from packages that set this up for them, and often relocate the directories to different locations on the file system.

wcawijngaards avatar Nov 11 '24 09:11 wcawijngaards