nixos/continuwuity: no way to use `DynamicUser`

[sodiboo]

Nixpkgs version

• Unstable (25.11)

Describe the bug

The continuwuity module has this snippet:

nixpkgs/nixos/modules/services/matrix/continuwuity.nix

Lines 219 to 221 in c87b95e

	DynamicUser = true;
	User = cfg.user;
	Group = cfg.group;

That's all good; it will allocate a dynamic user and try to give it the configured name (instead of a random/default one). Unless the user already exists.

It also creates the user by default:

nixpkgs/nixos/modules/services/matrix/continuwuity.nix

Lines 194 to 204 in c87b95e

	users.users = lib.mkIf (cfg.user == defaultUser) {
	${defaultUser} = {
	group = cfg.group;
	home = cfg.settings.global.database_path;
	isSystemUser = true;
	};
	};
	users.groups = lib.mkIf (cfg.group == defaultGroup) {
	${defaultGroup} = { };
	};

This is strange, because it immediately negates the effects of DynamicUser= by default? In particular, the matrix-conduit module never did this, which is the one i've been using and i'm trying to upgrade from.

But i guess i can just give it a garbage name and group, which isn't allocated? Then i get DynamicUser=? Well, no, because it also asserts that the user is statically allocated:

nixpkgs/nixos/modules/services/matrix/continuwuity.nix

Lines 184 to 191 in c87b95e

	{
	assertion = cfg.user != defaultUser -> config ? users.users.${cfg.user};
	message = "If `services.continuwuity.user` is changed, the configured user must already exist.";
	}
	{
	assertion = cfg.group != defaultGroup -> config ? users.groups.${cfg.group};
	message = "If `services.continuwuity.group` is changed, the configured group must already exist.";
	}

So there is literally no way to make it use a dynamic user. ????? . Why is it configuring DynamicUser = true?

I would normally just open a PR to fix this, but i'm actually not sure how best to do that. If i was reviewing the original PR, i would have said to remove the assertions that the user is statically allocated, as well as not statically allocating the default user either. But i don't think just removing that is necessarily backwards-compatible now? Some care has to be taken.

Additional context

https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#DynamicUser=

If a statically allocated user or group of the configured name already exists, it is used and no dynamic user/group is allocated.

System metadata

• system: "x86_64-linux"
• host os: Linux 6.12.34, NixOS, 25.11 (Xantusia), 25.11.20250708.9807714
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.28.4
• channels(root): "nixos"
• channels(sodiboo): ""
• nixpkgs: /nix/store/bgl6ldj5ihbwcq8p42z3a0qzgqafgk2b-source

Notify maintainers

@nyabinary @snaakey

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[nyabinary]

This came from the conduwuit module which continuwuity was inherited from: the reasoning is laid out here: #353651 (comment)
I don't know if anything has changed since then though.

[sodiboo]

Hm. That makes sense, actually. My existing system was just using a TCP port, so I never actually ran into that issue, and I wanted to use socket activation in the future (though I don't think continuwuity currently supports that?); which also bypasses any permission issues as the socket can belong to an entirely separate user than the service. For the common "create a socket path" case I can see why it is necessary to have statically controlled permissions; that way they don't need to be world readable (a+rw (666), as I spotted previously being the recommendation in that PR).

I don't think anything has fundamentally changed. But at least I understand now why it was like this. Now, I'm curious though, how come this was never an issue for the martrix-conduwuit module? Did the authors just not use Unix sockets, or did they make them with a+rw permissions?

[sodiboo]

I managed to actually get around that restriction by using systemd-socket-proxyd. the "correct" solution would be for continuwuity to support socket activation; but this little-known utility does allow emulating socket activation.