Created attachment 913283 [details] emerge --info net-dns/knot Service knot under version 3.4.2 crashes just after calling `rc-service knot start` — not during — with this error in its log: ``` 2024-12-04T03:06:54+0100 info: Knot DNS 3.4.2 starting 2024-12-04T03:06:54+0100 info: loaded configuration file '/etc/knot/knot.conf', mapsize 500 MiB 2024-12-04T03:06:54+0100 info: using UDP reuseport, incoming TCP Fast Open 2024-12-04T03:06:54+0100 info: binding to interface <IP addr> 2024-12-04T03:06:54+0100 error: cannot bind address <IP addr> UDP (operation not permitted) 2024-12-04T03:06:54+0100 critical: failed to configure server ``` with `IP addr` the address from the `listen` directive; with the `@port` inside, also tested without. However, without any `listen` directives, the logs got those messages, the one about capabilities: ``` 2024-12-04T03:07:29+0100 info: Knot DNS 3.4.2 starting 2024-12-04T03:07:29+0100 info: loaded configuration file '/etc/knot/knot.conf', mapsize 500 MiB 2024-12-04T03:07:29+0100 warning: no network interface configured 2024-12-04T03:07:29+0100 info: process not allowed to set capabilities, skipping 2024-12-04T03:07:29+0100 info: loading […] zones ../.. ``` As we can see in the emerge output, the USE flag `caps` is already set: ``` [ebuild U ~] net-dns/knot-3.4.2:0/15.9.4::gentoo [3.2.9:0/13.9.4::gentoo] USE="authsignal%* caps cookies daemon%* dnsproxy fastparser idn noudp onlinesign queryacl rrl stats synthrecord utils whoami -dbus% -dnstap -doc -doh -geoip -pkcs11% -quic -systemd -test% -xdp (-libidn2%*)" 1,595 KiB ``` For information, this is the same configuration than previous version 3.2.9, which still works after downgrading to restore service. Note: I also saw an error about failing to load a zone, a zone which is currently working and was dumped from version 3.2.9, but I guess this is worth another issue, later.
Created attachment 913284 [details] net-dns/knot-3.4.2 build log.gz
Two ways to start knot : - default with 3.2.X and init script : knotd starts as root and drops itself extra capabilities after the daemon successfully starts. In this way, knot needs useflags caps. - default with 3.4.X and init-1 script : knotd starts with unprivileged user and capabilities are handled by openrc. In this way, openrc needs useflags caps. Capabilities should also be set in init script : capabilities="^cap_net_bind_service,^cap_setpcap" You could refer to knot-resolver : https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/knot-resolver/files/kresd.initd-r2 Maybe init script needs (commented or not) capabilities by default. Maybe your issue with file zone is about privileges too.
Could you post the server block of your config ?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=76953cdb865f54195a77df8a48899b59db54049e commit 76953cdb865f54195a77df8a48899b59db54049e Author: Nicolas PARLANT <nicolas.parlant@parhuet.fr> AuthorDate: 2024-12-04 10:45:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-04 12:57:07 +0000 net-dns/knot: setcap for OpenRC init script. Add confd Set capabilities by default in init, as systemd service. No dep for openrc[caps] as it will be forced soon. Bug: https://bugs.gentoo.org/945837 Signed-off-by: Nicolas PARLANT <nicolas.parlant@parhuet.fr> Closes: https://github.com/gentoo/gentoo/pull/39588 Signed-off-by: Sam James <sam@gentoo.org> net-dns/knot/files/knot-2.init | 44 ++++++++++ net-dns/knot/files/knot.confd | 7 ++ net-dns/knot/knot-3.4.2-r1.ebuild | 167 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 218 insertions(+)
Hello, Thanks Nicolas for your work. (In reply to Nicolas PARLANT from comment #2) > Maybe your issue with file zone is about privileges too. No, I noticed a bit late in "Functionality" from "Upgrade 3.2.x to 3.3.x" this entry: https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#functionality > Semantic checks don't allow DS record at non-delegation point. (In reply to Nicolas PARLANT from comment #3) > Could you post the server block of your config ? Here it is: ``` server: version: # empty to disable version of the server software TXT response rundir: /run/knot user: knot:knot listen: ["<IPv6_addr>@53", "<IPv4_addr>@53"] ```
I just updated with your new modifications, it works, thanks. (don’t forget to clean the unused init file ;-)) You can mark as resolved IMHO.
One more comment, should we push upstream the issue about `info: process not allowed to set capabilities, skipping`, which is not displayed before the error when binding? I think it would have save me some time in debugging.
(In reply to Thibaud CANALE from comment #5) > No, I noticed a bit late in "Functionality" from "Upgrade 3.2.x to 3.3.x" > this entry: > https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#functionality > > Semantic checks don't allow DS record at non-delegation point. This is the problem of skipping too many versions. (In reply to Thibaud CANALE from comment #6) > You can mark as resolved IMHO. I can't change status myself, you should. (In reply to Thibaud CANALE from comment #7) > One more comment, should we push upstream the issue about `info: process not > allowed to set capabilities, skipping`, which is not displayed before the > error when binding?> > I think it would have save me some time in debugging. I think these are normal steps: binding with privileges then set capabilities. But you couldn’t do either.
(In reply to Nicolas PARLANT from comment #8) > (In reply to Thibaud CANALE from comment #6) > > You can mark as resolved IMHO. > I can't change status myself, you should. Done. > (In reply to Thibaud CANALE from comment #7) > > One more comment, should we push upstream the issue about `info: process not > > allowed to set capabilities, skipping`, which is not displayed before the > > error when binding?> > > I think it would have save me some time in debugging. > I think these are normal steps: binding with privileges then set > capabilities. But you couldn’t do either. Okay, I thought capabilities was necessary to "bind with privileges" without being root (for "privileges" port of course).
> > (In reply to Thibaud CANALE from comment #7) > Okay, I thought capabilities was necessary to "bind with privileges" without > being root (for "privileges" port of course). Yes, it is. For your log : - When listen is defined, knotd cannot bind because it was started by unprivileged knot user, without capabilities > critical error - When listen is not defined, knotd does not use any default values, does not consider this as a critical error, continues without binding and then : * sets new uid/gid but process is already run as knot:knot as defined * drops capabilities. And log msg can be misinterpreted. For knotd process, "not allowed to set capabilities" = "process has no capabilities to drop". Confusion comes too from my first message, that was incorrect : - default with 3.2.X and init script : knotd starts as root, *binds to interfaces and updates process to unprivileged user defined* after the daemon successfully starts.
