Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Testing showed that the existing documentation regarding password override
ordering was incorrect. This commit corrects the errors and refactors
the way the text is constructed to make updating future ordering
changes significantly easier.
Before the error message only mentioned isSystemUser/isNormalUser which
lead to a confusing situation when setting isNormalUser and an uid like
500 which would generate an error like:
error:
Failed assertions:
- Exactly one of users.users.other.isSystemUser and users.users.other.isNormalUser must be set.
from which you cannot know that setting the uid to 500 *and* setting
isNormalUser is the actual problem.
With this patch the error looks like:
error:
Failed assertions:
- A user cannot have a users.users.fixme.uid set below 1000 and set users.users.fixme.isNormalUser.
Either users.users.fixme.isSystemUser must be set to true instead of users.users.fixme.isNormalUser
or users.users.fixme.uid must be changed to 1000 or above.
This was suggested since it might make it a little easier to identify
the places where the definitions come from.
Retrieving the effective definitions from the module-system seems
non-trivial, especially for submodules though, hence only the values are
shown for now.
I'd argue that especially the `password` option are mostly a convenience
thing for test setups. If the password is an actual secret, it should be
treated as such, i.e. `hashedPasswordFile` should be used.
For the `shadow` VM test, the new section of the warning looks like
this:
The values of these options are:
* users.users."leo".hashedPassword: "$6$ymzs8WINZ5wGwQcV$VC2S0cQiX8NVukOLymysTPn4v1zJoJp3NGyhnqyv/dAf4NWZsBWYveQcj6gEJr4ZUjRBRjM0Pj1L8TCQ8hUUp0"
* users.users."leo".hashedPasswordFile: null
* users.users."leo".password: null
* users.users."leo".initialHashedPassword: "!"
* users.users."leo".initialPassword: null
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
The update-lingering activation script currently fails during rebuilds.
This happens when removing a user with linger enabled.
The call to loginctl disable-linger runs for the non-existent user.
This returns an error code which causes the failure.
To mitigate this, this PR removes any residual linger files.
These are files named for the user in /var/lib/systemd/linger.
A simple check for user existence determines whether to delete the file.
This happens before the call to disable-linger to avoid any errors.
Fixes#283769.
After 4b128008c5 it took me a while in a
test setup to find out why `root` didn't have the password anymore I
declared in my config.
Because of that I got reminded how the order of preference works for the
password options:
hashedPassword > password > hashedPasswordFile
If the user is new, initialPassword & initialHashedPassword are also
relevant. Also, the override is silent in contrast to any other
conflicting definition in NixOS.
To make this less surprising I decided to warn in such a case -
assertions would probably break too much that technically works as
intended.
Also removed the `initialHashedPassword` for `root`. This would cause a
warning whenever you set something in your own config and a `!` is added
automatically by `users-groups.pl`.
`systemd-sysusers` also seems to implement these precedence rules, so
having the warning for that case also seems useful.
I recently set up a new machine with tmpfs-on-root
and switched to mutableUsers = false as part of that.
I missed that an existing user with `shell = null`
was no longer valid as part of this change.
(`shell = null` is still useful for `mutableUsers = true`.)
Add an assertion to prevent future issues.
Also fix a typo in an option name in a comment,
this confused me slightly
(I originally planned to extend that existing assertion.)
If we include users with unset groups, we get this very confusing
message, with invalid Nix code:
- The following users have a primary group that is undefined: qyliss
Hint: Add this to your NixOS configuration:
users.groups. = {};
We don't need to include such users in this check, since they'll be
caught anyway by this one:
- users.users.qyliss.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.qyliss.group = "qyliss";
users.groups.qyliss = {};
Before: `users.users.user1.group = "group-not-defined-anywhere-else"`
would result in user1 having the primary group `nogroup`, assigned at
activation time and only with a (easy to miss) warning from the
activation script. This behaviour is a security issue becase no files
should be owned by `nogroup` and it allows for unrelated users (and
services) to accidentally have access to files they shouldn't have.
After: The configuration above results in this eval error:
- The following users have a primary group that is undefined: user1
Hint: Add this to your NixOS config:
users.groups.group-not-defined-anywhere-else = {};
This avoids the possible confusion with `passwordFile` being the file
version of `password`, while it should contain the password hash.
Fixes issue #165858.
Since #246772, cross compiled NixOS is broken because the DateTime perl
package that was used in the update-users-groups.pl script depends on
Testutf8 which does not cross compile (see #198548).
This PR drops the DateTime dependency in favour of TimePiece, which has
less dependencies and whose closure does cross compile.
0d7cd66652 broke validation for hashes with options
such as those generated with `mkpasswd --method=sha-512 --rounds=1000000`:
$6$rounds=1000000$xpzZ6Rfg873gZnDY$RxS7lpVnohfDrrKG3lt9UFHED1KoiPGzH7zQv/HzwalZepo/IfFtxw05ap25duEJSKYhC14.Fn9eXszEpWVtF.
This fixes it.
Updates the warnings message for statefully set up passwords, now that
weak algorithms have been removed from our libxcrypt package.
Additionall we now add proper validation for hashing schemes used in
`hashedPassword`.
Neither will prevent a rebuiild, but instead issue a warning, that this
requires immediate remediation, or else users will be unable to login.
Reuses the crypt scheme ids as provided by the libxcrypt package.
mkAliasOptionModule should not default to mdDoc descriptions because
that can break out-of-tree users of documentation infrastructure. add an
explicitly-MD variant for now, to be removed some time after the MD
transition is complete.
