nixos/dendrite: signing key can only be accessed by root

[McSinyx]

Describe the bug

The Dendrite service seems to move /var/lib/dendrite/matrix_key.pem inside /var/lib/private (mode 700 own by root) and symlink it back, and thus mess with the permission an operator could have intended to give the key. Personally I created the key with the dendrite user which is also given access with the PostgreSQL database to run the service and expect that user can read the key.

This affects manual account creation via create-account, which requires permission to both the database and the key.

Steps To Reproduce

Steps to reproduce the behavior:

1. Create the key using user dendrite:

   sudo -u dendrite mkdir -p /var/lib/dendrite nix-shell -p dendrite --run 'sudo -u dendrite generate-keys --private-key /var/lib/dendrite/matrix_key.pem'

2. Enable dendrite service

3. In a directory readable by dendrite (e.g. /tmp), since the command tries to look up relative path:

   nix-shell -p dendrite --run 'sudo -u dendrite create-account -config /run/dendrite/dendrite.yaml -username foo -password bar'

Expected behavior

Account created successfully.

Notify maintainers

@mjlbach because of https://github.com/NixOS/nixpkgs/commit/ff43bbe53e370fa1072e952b89d0a32fb1dfda3a#diff-80755fce7bad4cc6213e6e0bdf661ebe8b3c5347cd4ebd2e636bfe1c04253a4cR155

Metadata

• system: "x86_64-linux"
• host os: Linux 5.10.98.23-livepatched, NixOS, 22.05 (Quokka), 22.05pre377574.fb222e00868
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.8.0
• channels(root): "nixos"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[rnhmjoj]

The /var/lib/private thing is explained in systemd.exec(5):

If DynamicUser= is used, the logic for CacheDirectory=, LogsDirectory= and StateDirectory= is slightly altered: the directories are created below /var/cache/private, /var/log/private and /var/lib/private, respectively, which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/cache, /var/log and /var/lib.

Basically Dendrite is running with a dynamically allocated user that exists as long as the service is running. Since, file systems only store users IDs in the file ownership, if another user gets assigned (in a very rare case) the ID previously used by Dendrite (recycled) it could peek at its files, that's why systemd moves the service directories under one no one can traverse except root.

It seems you created the /var/lib/dendrite directory before systemd set up the directory: I'm a bit baffled at this because the dendrite user is not supposed to exists at this point. I'm not sure how/what ownership you gave the key.

What happens if you create the key after starting the service? (Is this even possible?)

Anyway, I'd suggest you use systemd.tmpfiles.rules to make sure the permissions/ownership are more persistent.