This option is made uncondiotional in systemd 258 [1].
Earlier, it defaulted to true on kernels newer than 4.15,
which applies to all supported nixos kernels.
This means removing the option does not change behavior.
[1] 29da53dde3
This brings our `run0` in line with the upstream defaults:
bcc73cafdb/src/run/systemd-run0.in
While working on `auditd`, i noticed differences in how `run0` behaves
in regard to `/proc/$pid/sessionid` and `/proc/$pid/loginuid`. Particularly,
both files were set to `4294967295`, the magic value denoting `unset`.
While the manual page says elevators such as sudo should not set the loginuid,
run0 is a bit of a special case: The unit spawned by it is not child of
the running user session, and as such there is no id to inherit.
`systemd` upstream uses `pam_loginuid`, and for consistency we should too.
Especially because it prevents a whole lot of pain when working with `auditd`.
As to pam mounts:
On nixos we enable those if they are globally enabled. Upstream does not.
Considering the password entered into polkit is usually not the user password
of the account which will own the unit, pam mount will fail for any partition
which requires a password. Thus it makes sense to also disable pam mounts
for our run0, it prevents unnecessary unexpected pain.
This ensures the tmpfiles resetup service has permissions
to create suid/sgid files, even if `DefaultRestrictSUIDSGID`
is set in system.conf. This is required, as tmpfiles
are used to e.g. set file permissions on the journal
directory.`DefaultRestrictSUIDSGID` is a new feature
coming in systemd 258 [1].
[1] https://github.com/systemd/systemd/pull/38126
Before this change, systemd-oomd startup was flaky at least with
either systemd-sysusers or userborn enabled. It would restart several
times until users were provisioned, so that it finally succeeded.
An alternative would be to use a DynamicUser which was my first
approach, before I discovered that upstream added the after statement
in Dec 2024[1]. DynamicUsers could have further
implications (sandboxing, etc), so we follow upstream here.
It's not clear to me we why Upstreams "After=systemd-sysusers.service"
doesn't show up on nixos-unstable systems (systemd v257.6).
Userborn is covered, as its unit is aliased to systemd-sysusers.service.
The following test succeeded after this change on x86_64-linux:
nix-build -A nixosTests.systemd-oomd
[1]: 36dd429680
When running with a xfs root partition and using systemd for stage 1
initrd, I noticed in journalctl that fsck.xfs always failed to execute.
The issue is that it is trying to use the below sh interpreter:
`#!/nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37/bin/sh -f`
but the file does not exist in the initrd image.
/nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37/bin/**bash**
exists since it gets pulled in by some package, but the rest of the
directory is not being pulled in.
boot/systemd/initrd.nix mentions that xfs_progs references the sh
interpreter and seems to explicitly try to address this by adding
${pkgs.bash}/bin to storePaths, but that's the wrong bash package.
Update the `storePaths` value to pull in `pkgs.bashNonInteractive`
rather than `pkgs.bash`.
Fixes#361592.
I was able to test this change by doing the following:
1. Create a file named “test-systemd-run0.nix” that contains this Nix
expression:
let
nixpkgs = /path/to/nixpkgs;
pkgs = import nixpkgs { };
in
pkgs.testers.runNixOSTest {
name = "test-systemd-run0";
nodes.machine = {
security.polkit.enable = true;
};
testScript = ''
start_all()
machine.succeed("run0 env")
'';
}
2. Replace “/path/to/nixpkgs” with the actual path to an actual copy of
Nixpkgs.
3. Run the integration test by running this command:
nix-build <path to test-systemd-run0.nix>
`user-.slice` does not seem to exist, and the config we generate for it is
rejected by systemd (see `systemctl status user-.slice`).
I suppose that what was really intended here, was to configure
`user.slice`, which is the one that is documented in `man systemd.special`.
Reported-by: Ian Sollars <Ian.Sollars@brussels.msf.org>
