Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#61723 - [unbound] absolute path relative to the original root not working

Attached to Project: Community Packages
Opened by ipp (n8V8r) - Monday, 11 February 2019, 17:09 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 31 March 2019, 16:31 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Description: My understanding is that chroot is enabled by default, during build time and in the settings. According to the upstream documentation:

> All other file paths (working dir, logfile, roothints, and key files) can be specified in several ways: as an absolute path relative to the new root, as a relative path to the working directory, or as an absolute path relative to the original root. In the last case the path is adjusted to remove the unused portion.

Having set an absolute path relative to the original root however returns (unbound-checkconf):

> /etc/unbound/var/log/unbound: No such file or directory

For some reason it seems that > /etc/unbound < is not dropped as it would be expected however.


Something similar happens with zonefile path in

zonefile: "/var/unbound/zone_files/root"

Whilst > unbound-checkconf < does not produce an error/warning during the startup of unbound however it is observed/reported

> unbound error: could not open /var/unbound/zone_files/root.tmp7789: No such file or directory

If the zonefile path is pointing however to /etc/unbound/zone_files/root there is no such error.


Additional info:
* package version(s) 1.9.0-1
* config and/or log files etc.

username: "unbound"
directory: "/etc/unbound"
pidfile: "/run/"
logfile: "/var/log/unbound/unbound.log"

also tried without > directory: "/etc/unbound" <

Steps to reproduce:

1. install unbound
2. configure unbound with absolute path(s)
3. unbound-checkconf, respectively start unbound whilst > journalctl -f <


Having deployed unbound 1.9.0 in another node (OpenWRT) those issues are not exhibited. The governing build congf
This task depends upon

Closed by  Gaetan Bisson (vesath)
Sunday, 31 March 2019, 16:31 GMT
Reason for closing:  Not a bug
Comment by Gaetan Bisson (vesath) - Sunday, 31 March 2019, 16:29 GMT
It is important from a security standpoint that unbound should chroot to its directory after startup. This is also the default behavior. As you can see our PKGBUILD and service file nowhere explicitly ask unbound to do this.

So unbound will chroot to "/etc/unbound" and will obviously not be able to access any file outside of that hierarchy. As you point out, the doc says "All other file paths [...] can be specified [...] as an absolute path relative to the original root. In [that] case the path is adjusted to remove the unused portion." What this means is that if you give a path like "/etc/unbound/log/unbound.log" unbound will notice that it starts with the chroot path, so it will remove it to get a path that works from inside the chroot, in this case "/log/unbound.log". If you, the user, want to check out that file, since you live outside of unbound's chroot, you have to use the path "/etc/unbound/log/unbound.log".

Now if you specity "/var/log/unbound/unbound.log" unbound understands it as an absolute path inside the chroot which translates to you, the user outside the chroot, to "/etc/unbound/var/log/unbound/unbound.log".

It's all perfectly normal. There's no way for unbound to chroot and be able to access files outside the chroot. If you really need to write to /var you can either chroot to some directory there (if all the files unbound needs can be copied there) or just disable chrooting altogether. Refer to unbound's documentation.