Provide remote-control over Unix domain socket

[michael-o]

Currently, remote control forces users to fiddle with certificates to make transport and authentication secure even if it is listening on localhost. Proposal is to utilize Unix domain sockets as an alternative to TCP sockets.

Benefits:

• No fiddling with certificates
• No open TCP socket for all users on the system
• UDS can be protected by OS/FS means, e.g., unbound:wheel and everyone in wheel can communicate with the process
• and likely others

Note: UDS is now also available on Windows as well.

Default path could be /var/run/unbound-remote-control.sock. Ideally configured in a way that it does not need to be passed constantly to unbound-control(8) (read from config file, like -s).

New option could be -u /path/to/socket.

[DavidOsipov]

Moreover, Unix domain sockets are quite fast. I've already asked Adguard home team, providing the pros and cons, to implement it in their software

[michael-o]

Moreover, Unix domain sockets are quite fast. I've already asked Adguard home team, providing the pros and cons, to implement it in their software

Oh man, you stunned me. I thought my father to my Unbound ticket, then I realized you share the same name.

[wcawijngaards]

The feature already exists. Set the control-interface to the absolute path to the unix domain socket. If you enable that in the default config file, then also unbound-control picks that up from the config file and uses the file.

With control-interface: "/var/run/unbound-remote-control.sock" in the remote-control section. Set control-enable: yes to turn it on. With control-use-cert: no as an additional setting, you do not need to have the certificates, since the communication is limited to the local host.

[michael-o]

Indeed, that seems truly like an issue in the docs. Read it multiple times:

If you set it to an absolute path, a local socket is used.

It obviously shoud mention Unix domain socket, local socket is just totally overlooked. It can be simply misunderstood with a TCP socket listening on localhost.

[michael-o]

Works for me now:

# sockstat -u -l | grep unbound
unbound  unbound    62539 19 stream /var/run/unbound-remote-control.sock

and denied:

$ unbound-control stats
[1646037267] unbound-control[62576:0] error: connect: Permission denied for /var/run/unbound-remote-control.sock

@wcawijngaards Should I open a followup ticket for docs?

[wcawijngaards]

Does the unbound-control process have the privileges to access the file in the /var/run directory? Perhaps you need to sudo that, or set the permissions on the socket the way you like it.

I can update the docs :-)

[michael-o]

Does the unbound-control process have the privileges to access the file in the /var/run directory? Perhaps you need to sudo that, or set the permissions on the socket the way you like it.

The error is just fine since I tried to access the socket as an unpriviledged user. As root I am perfectly able to access it:

root@deblndw011x:~
# unbound-control status
version: 1.14.0
verbosity: 1
threads: 8
modules: 2 [ validator iterator ]
uptime: 319 seconds
options: reuseport control(namedpipe)
unbound (pid 62539) is running...

[wcawijngaards]

Added a commit to fix the documentation issue that you talked about. Is that something that fixes the text you think?

Good to see that it is working for you.

[michael-o]

Added a commit to fix the documentation issue that you talked about. Is that something that fixes the text you think?

Good to see that it is working for you.

Almost, I would even make it in the first sentence:

If you set it to an absolute path, a unix domain socket is used. This socket
does not use the certificates and keys, so those files need not be present.

[michael-o]

Dank u

[wcawijngaards]

Okay, I updated to the new text in the commit. Good to fix the documentation!