Disclaimer

Please note that I've discovered knot yesterday and thus don't know it well at all. I'm just hacking my way to make it work, and thus this PR may not be the right thing to do.

Motivation for this change

NixOS' services.knot module currently uses systemd's DynamicUser coupled with StateDirectory, but knotd is not the only executable which must be able to operate on the StateDirectory, keymgr must too be able to manage keys within it. keymgr could be run as root but then the permissions of the keys wouldn't be right for knotd. In some condition DynamicUser can run a recursive chown but it would be at the restart of service and AFAIU, only if the StateDirectory is owned by the wrong user, but here this is the sub directory keys/ which is would be owned by root and not knot.

Things done

This patch wraps keymgr with systemd-run --pipe --uid knot -p DynamicUser=yes -p StateDirectory=knot to run it with the proper mount namespace allowing it to reach /var/lib/private/knot, bypassing the /var/lib/private/ protection restricted to root by the DynamicUser machinery.
This workaround still has the (minor) inconvenient to require to run keymgr as root.
--working-directory="$PWD" is also use to be able to give relative paths to keymgr (eg. for import-bind) but this may fail if the current directory is not accessible to the knot dynamic user (even if it's just a keymgr $zone list).

Alternatives

Use a SETGID bit

I've not tested it but I thought that if StateDirectoryMode = "2770" instead of 0700 then the knot group will be inherited by sub dirs and files, and thus running keymgr as root shouldn't be a problem. However if kasp/data.mdb is rw by the group it is not the case of kasp/keys/ which is created with different rights for the user and the group, the later is not allowed to write in it, thus automatic key generation by knotd may not work as expected (it won't be able to write/delete the keys/*.pem files). Maybe this could be worked around by wrapping keymgr with a umask 007 or a chmod -R g+w afterward.

Remove DynamicUser

I'm proposing this patch which assumes that there is a good reason to use DynamicUser and thus keep it, but I don't understand the benefit of DynamicUser for knotd, why not using a fixed system user like other NixOS services do?
AFAICS this alternative would be better for me as this would also let me open the OUTPUT firewall chain only for this knot system user (so it can notify the DNS slave servers) :

DNS(ACCEPT) $FW net {user=${users.users.knot.name}}

Currently I must open the firewall for all users, and can only specify the IP address of the DNS slave servers:

DNS(ACCEPT) $FW net:217.70.177.40 # for knot to notify ns6.gandi.net

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.