27.04.2022 19:38, ceddral wrote: ..
Tested it, as far as i can tell it works for me with chroot: "/var/lib/unbound" and control-interface: "/run/unbound-control.socket"
Thank you for confirming this. I too did the similar test locally, you made me curious.
(and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify in the systemd service file)
This is not necessary anymore, but I guess it is nicer this way. The difference is that the setup script (/usr/libexec/unbound-helper) does the mount already but this mount is visible for all other processes. While .service way makes it private to this process (with its own namespace). This whole thing isn't actually necessary, it is only needed to notify systemd when unbound is finished initializing. It might be easier in cases like this if systemd passed an open file descriptor to the process where it can write to, so there's no need to open a (named) socket. I wonder if there's a way to avoid this bind-mount...
My test was `unbound-control stats` says something.
Yeah. I think it's a good idea to switch to unix socket. Please also note that linux actually honors the file permissions for the socket files, - unlike on some other systems. And there's one more thing: unbound chowns the socket to unbound user. I don't know why it is doing this, - ditto for the pid file. FWIW, I tend to chroot it to /etc/unbound, - which needs bind-mounting of /var/lib/unbound to /etc/unbound/ somewhere, but reduces the need for copying /etc/unbound to /var/lib. This copying is bad: besides it makes reloading unbound more difficult, it is also very security-sensitive, I highly doubt the copy procedure is "secure enough". Creating files as root in a unprivileged /var/lib/unbound is problematic. See how I did root.key handling in unbound-helper. Thank you! /mjt
