Package: knot Version: 1.3.0~rc3-1 In 509ad7fe247fea6f5a60f231b3496fb4d8bc778b, the knot package introduced the knot user and make certain files owned by it by default.
/etc/knot/knot.conf also has a (commented-out) line:
# user: knot:knot
If the local administrator has launched knot without commenting out this
line (which happens by default upon initial installation), then
/var/lib/knot/timers/ (and its children lock.mdb and data.mdb) will be
created owned by root:root.
As a result, when the local administrator uncomments that line and tries
to restart knot, knot raises errors in its logs with:
warning: cannot open persistent timer DB '/var/lib/knot/timers' (operation
not permitted)
as a workaround, it's possible to change ownership over these timers, or
to move them out of the way. But this shouldn't be necessary.
The non-privileged user should be used by default, without needing any
changes.
Furthermore, it's not clear why /etc/knot or /etc/knot/knot.conf need to
have the ownership/permissions restricted the way that they are (they
are currently managed as knot:knot and unreadable by the world).
If the daemon is running as the non-privileged user, presumably it
should not be allowed to rewrite its own configuration file.
I propose that these configuration files and directories should be owned
by the superuser, not by the knot user. If they need to be made group
"knot" for readability, that's a separate concern.
I also doubt whether it makes sense for knot.conf avoid world-readablity
by the package itself. As far as i can tell, there are three potentially
secret things in knot.conf:
* pin-value in keystore:config (for a pkcs11 keystore whose security is
contingent on a PIN)
* key:secret (for TSIG use)
* acl information (for security-through-obscurity IP-filtered
master/slave relationships)
for installations that don't use these chocies, a world-readable
knot.conf is probably fine. It's also simpler to maintain if they're
root:root, and world-readable.
So perhaps if the administrator of a knot server has secrets in this
file, they can adjust the ownership and permissions accordingly, and the
package doesn't need to do it manually.
I think transitioning the package to always running the server as a
non-privileged user, and leaving the files alone is right way to fix
this bug.
A clean transition should of course support existing installations
without breaking them.
for systems using systemd, the [Service] section of knot.service should
probably contain:
User=knot
AmbientCapabilities=CAP_NET_BIND_SERVICE
I'll probably try to make these changes (including
backward-compatibility for prior installs) in knot before the release of
buster, so that after the release of buster we can drop the backward
compatibility steps.
Please comment on this ticket if you have an objection to this
privilege-limiting approach.
--dkg
signature.asc
Description: PGP signature
