Project

General

Profile

Actions

Bug #17069

closed
EK

DNS Resolver TLS key is written 0600 owned by root, unbound cannot read it after startup

Bug #17069: DNS Resolver TLS key is written 0600 owned by root, unbound cannot read it after startup

Added by Emre K 6 days ago. Updated 6 days ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
DNS Resolver
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.9.x
Affected Architecture:
amd64

Description

Turning on Services > DNS Resolver > General Settings > Enable SSL/TLS Service writes the private key to /var/unbound/sslcert.key owned by root with mode 0600, and points tls-service-key at it. unbound runs as user unbound.

That works at boot, because unbound parses its config as root before it drops privileges. It stops working the moment anything makes a running unbound read the key again, which it does whenever the file's timestamp changes and a reload comes in. At that point it's running as unbound and gets permission denied.

Current state on my firewall with SSL/TLS enabled:

# ls -ld /var/unbound
drwxr-xr-x  8 unbound unbound 35 Sep  2 01:25 /var/unbound

# grep -n '^username:' /var/unbound/unbound.conf
40:username: "unbound" 

# ps -axo user,command | grep '[u]nbound -c'
unbound /usr/local/sbin/unbound -c /var/unbound/unbound.conf

# grep -n 'tls-service-key' /var/unbound/unbound.conf
95:tls-service-key: "/var/unbound/sslcert.key" 

# ls -l /var/unbound/sslcert.key
-rw-------  1 root unbound 288 Sep  2 01:24 /var/unbound/sslcert.key

# su -m unbound -c 'cat /var/unbound/sslcert.key' >/dev/null; echo "exit=$?" 
cat: /var/unbound/sslcert.key: Permission denied
exit=1

The directory is unbound:unbound and the key inherits group unbound, but the mode is 0600 so the group doesn't help

TO REPRODUCE:
With the DNS Resolver running and SSL/TLS enabled:

touch /var/unbound/sslcert.key
unbound-control -c /var/unbound/unbound.conf fast_reload

result:

unbound[<pid>]: [<pid>:14] error: error for private key file: /sslcert.key
unbound[<pid>]: [<pid>:14] error: Error in SSL_CTX use_PrivateKey_file crypto error:8000000D:system library::Permission denied
unbound[<pid>]: [<pid>:14] error: and additionally crypto error:10080002:BIO routines::system lib
unbound[<pid>]: [<pid>:14] fatal error: could not set up listen SSL_CTX

(The path in the log shows without the chroot prefix.)

The process does not exit after that. It keeps udp/53, tcp/53 and tcp/953 bound, answers nothing, and ignores SIGTERM. kill -9 is the only thing that ends it.

Please test this on something you don't need. On my box it took a power cycle.

The firewall runs Kea, and every DHCP lease event calls kea2unbound, which issues fast_reload. That works fine normally, because a restart rewrites the key and then starts a fresh unbound that reads it as root.

It breaks when two reconfigure runs overlap. My WAN port flapped repeatedly for about 45 minutes, and the resulting link/newwanip events restarted unbound 27 times, sometimes several at once. I have three bind: address already in use failures in the system log from that window, so two runs were definitely in flight together. One of them rewrote the key underneath the unbound the other had just started, and the next lease event's fast_reload hit the fatal above.

After that, the GUI Restart button spun and did nothing, because the stop times out waiting for a process that won't die and the following start can't bind:

php-fpm[...]: NOTICE The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf'
returned exit code '1', the output was 'unbound[...]: error: bind: address already in use
unbound[...]: fatal error: could not open ports'

Reboot from the GUI hung the same way. DNS was down about 16 minutes until I power cycled it.

Changing the key so unbound can read it stops the fatal error. Disabling the TLS service also avoids it, which is what I've done for now.


Related issues 1 (1 open0 closed)

Is duplicate of Bug #16937: Unbound cannot reload due to SSL/TLS certificate file permissionsFeedbackJim Pingle

Actions
Actions

Also available in: Atom