Feat: support providing a secret file to frp service

[henningphan]

Background:
services.frp sometimes require a secret token to be set in services.frp.settings."auth.token". Auth.token can either be a string, which is insecure, or a file, by using frps include directive which will read an external file.

Problem with using the frps include directive is; to read the file the frps'user needs permissions, which is difficult to provide because its a systemd dynamicuser.

Potential solution 1: use systemd loadcredentials, believes it provides the secret file to the dynamicUser
https://discourse.nixos.org/t/better-way-to-get-secrets-into-systemd-units/34173/9

potential solution 2: set the User in systemd service, then I assume we can create a matching user and therefore know which user to set as owner to the secret file

Relevant to: @zaldnoay

[zaldnoay]

I think both solutions are feasible, but I prefer the first solution using LoadCredential. You can also refer to issue in the sops-nix repo. Although I may not have time to add this feature recently, I can spare some time for the review.

[henningphan]

I gladly do it, but im a busy in the near future so if someones faster than me go ahead. if not, then one day there will be a pull request :)

[henningphan]

seems we are partially blocked at least for the use case when we want to use auth.token, the server config doesnt support includes statements. Still possible to provide certs though.

[xokdvium]

Note that there is an alternative solution, which I implemented for rathole (which does basically the same thing a frp and also uses TOML for configuration). Unlike frp it does not support loading files via the configuration so LoadCredential was not a suitable solution , so I had to provide a services.rathole.credentialsFile that gets merged with the generated settings in ExecStartPre with elevated privileges (note the +). I imagine something similar could be done to support merging of fields that native include mechanisms can't handle:

seems we are partially blocked at least for the use case when we want to use auth.token, the server config doesnt support includes statements. Still possible to provide certs though.

nixpkgs/nixos/modules/services/networking/rathole.nix

Lines 111 to 119 in 2569d26

	ratholePrestart =
	"+"
	+ (pkgs.writeShellScript "rathole-prestart" ''
	DYNUSER_UID=$(stat -c %u ${runtimeDir})
	DYNUSER_GID=$(stat -c %g ${runtimeDir})
	${lib.getExe py-toml-merge} ${configFile} '${cfg.credentialsFile}' |
	install -m 600 -o $DYNUSER_UID -g $DYNUSER_GID /dev/stdin ${runtimeDir}/${mergedConfigName}
	'');
	mergedConfigName = "merged.toml";

This has the benefit of still using DynamicUser = true, by working around the need for hard-coding the user with correct permissions for reading the credentialsFile, since the actual reading (and merging) of credentialsFile gets done as root.

The merging of TOML files itself is done with a little python script:

nixpkgs/nixos/modules/services/networking/rathole.nix

Lines 11 to 45 in 2569d26

	py-toml-merge =
	pkgs.writers.writePython3Bin "py-toml-merge"
	{
	libraries = with pkgs.python3Packages; [
	tomli-w
	mergedeep
	];
	}
	''
	import argparse
	from pathlib import Path
	from typing import Any
	import tomli_w
	import tomllib
	from mergedeep import merge
	parser = argparse.ArgumentParser(description="Merge multiple TOML files")
	parser.add_argument(
	"files",
	type=Path,
	nargs="+",
	help="List of TOML files to merge",
	)
	args = parser.parse_args()
	merged: dict[str, Any] = {}
	for file in args.files:
	with open(file, "rb") as fh:
	loaded_toml = tomllib.load(fh)
	merged = merge(merged, loaded_toml)
	print(tomli_w.dumps(merged))
	'';

The only hacky part of this solution is getting the uid/gid of the DynamicUser. IIRC that hack was from pre-LoadCredential era that I yoinked from a systemd issue that I can't seem to find right now.

nixpkgs/nixos/modules/services/networking/rathole.nix

Lines 114 to 115 in 2f75002

	DYNUSER_UID=$(stat -c %u ${runtimeDir})
	DYNUSER_GID=$(stat -c %g ${runtimeDir})

[henningphan]

#409546

Turns out you can pass environment file to services, and that frp supports using env values in the config.