This allows other services to refer to the generated smokeping config,
which is e.g. necessary to run smokeping with nginx as frontend, rather
than thttpd.
The module was allowing specific chown syscalls, which is brittle because
there are several and different ones are used by glibc on different
architectures. For example, fchownat was already added to the allowlist for
aarch64, while on armv6l chrony crashes because chown32 is not in the
allowlist.
systemd provides the @chown syscall set, which includes all the chown
syscalls and avoids this brittleness. I believe the syscalls would all be
equivalent from an attacker's perspective, so there is unlikely to be any
security impact.
Headscale now supports passing the OIDC client secret via a file, as
added in [juanfont/headscale#1127][1127]. Lets use that.
The headscale option is `client_secret_path`; let's make it consistent
and rename the Nix option to this. Note that I wasn't able to do this:
mkRenamedOptionModule [ ... "client_secret_file" ] [ ... "client_secret_path" ]
I get such error:
error: evaluation aborted with the following error message: 'cannot find attribute `services.headscale.settings.oidc.client_secret_file''
[1127]: https://github.com/juanfont/headscale/pull/1127
The option `LinkLocalTCPPort` does not exist anymore in recent versions
of Yggdrasil. The port for incoming link-local connections is now
configured as part of the `MulticastInterfaces` option. Our
documentation should reflect that.
As far as I can tell the configFile option cannot have worked as
intended. The Yggdrasil systemd service uses a dynamic user. As it was,
there was no way to set the correct permissions on a config file
beforehand which would allow the dynamic user to read the config file
without making it readable for all users. But since the config file can
contain a private key it *must not* be world-readable.
The file must only be readable by root. The file has to be copied and
the permissions have to be fixed during service startup. This can either
be done in a ExecStartPre directive with the '+' prefix (which executes
that command with elevated privileges), or it can be done more
declarative with the LoadCredential directive. I have chosen the latter
approach because it delegates more work to systemd itself. It should be
noted that this has the minor tradeoff that the config file must not be
larger than 1 MB. This is a limit which systemd imposes on credential
files. But I think 1 MB ought to be enough for anybody ;).
