unbound systemd unit

acubens · 2024-06-16 03:12:50

Hi, there are two problems with the unbound package involving the systemd unit that starts it.

The first concerns remote control. If you set the "control-interface" option with an absolute path (example: /run/unbound/control) unbound will try to change the permissions to unbound:unbound but will fail because the relative capability is missing in the systemd unit.

The second concerns the chroot function (enabled by default).
Unbound after calling chroot() will try to access /etc/group and /etc/nsswitch. If it doesn't find them it starts anyway but if the user activates the cachedb module the lack of /etc/group will block startup.

So I had to create these:

[root@arch unbound.service.d]# cat /etc/systemd/system/unbound.service.d/control.conf
[Service]
RuntimeDirectoryMode=755
# Unbound require chown to change the owner of its control socket.
# Owner of /run/unbound/control will be set to unbound:unbound.
CapabilityBoundingSet=CAP_CHOWN

[root@arch unbound.service.d]# cat /etc/systemd/system/unbound.service.d/redis.conf
[Unit]
After=redis.service

[Service]
# Setup Redis CacheDB inside chroot.
TemporaryFileSystem=/etc/unbound/etc:ro
BindReadOnlyPaths=-/etc/group:/etc/unbound/etc/group
BindReadOnlyPaths=-/etc/nsswitch.conf:/etc/unbound/etc/nsswitch.conf"
BindReadOnlyPaths=-/run/redis/control:/etc/unbound/run/redis/control

I think it's a good idea to add CAP_CHOWN, /etc/group and /etc/nsswitch to systemd unit.

WorMzy · 2024-06-16 09:25:46

The service file is provided by upstream: https://github.com/NLnetLabs/unbound/bl … service.in, if you think these changes are necessary, open a bug report or pull request there. Maybe update the ArchWiki in the meantime.

Mod note: not a pacman issue, moving to networking.

Arch Linux

#1 2024-06-16 03:12:50

unbound systemd unit

#2 2024-06-16 09:25:46

Re: unbound systemd unit

Board footer