When a disposition is not set in a user record, systemd determines user
disposition depending on the range the user's UID falls in. For system
users with UIDs above 1000, this will cause them to be incorrectly
identified as "regular" users.
This will cause `userctl` to report the user as a regular user, and more
importantly, `systemd-homed` will not run the first boot user creation
flow, as regular users are already present on the machine (when they are
really system users).
The most common source of high UID system users will undoubtedly be Nix
build users, so the warning provides additional guidance on how to
remove them or adjust their IDs to be within the system range.
The warning is shown only when userdbd/homed is enabled, and the option
to hide the warning is deliberately hidden, to ensure users will have to
read and acknowledge the warning before proceeding, as otherwise users
could end up deploying an OS with no users and no way of creating one
due to the first boot flow being skipped.
PR #431115 changed extraStructuredConfig to structuredExtraConfig to
follow the deprecation warning about `extraConfig`. However,
`extraStructuredConfig` was mentioned in several places in the docs that
weren't addressed. Also, using this would silently fail since the code
in question would still accept the old key.
This patch updates the docs accordingly and throws an error if the
code-path is reached and `extraStructuredConfig` is being used.
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>
