A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
This change is needed because the order of profiles correlate to the
order in PATH, therefore "/etc/profiles/per-user/$USER" always appeared
after the system packages directories.
With #36556, a check was introduced to make sure the user and group
names do not exceed their respective maximum length. This is in part
because systemd also enforces that length, but only at runtime.
So in general it's a good idea to catch as much as we can during
evaluation time, however the maximum length of the group name was set to
16 characters according groupadd(8).
The maximum length of the group names however is a compile-time option
and even systemd allows more than 16 characters. In the mentioned pull
request (#36556) there was already a report that this has broken
evaluation for people out there.
I have also checked what other distributions are doing and they set the
length to either 31 characters or 32 characters, the latter being more
common.
Unfortunately there is a difference between the maximum length enforced
by the shadow package and systemd, both for user name lengths and group
name lengths. However, systemd enforces both length to have a maximum of
31 characters and I'm not sure if this is intended or just a off-by-one
error in systemd.
Nevertheless, I choose 32 characters simply to bring it in par with the
maximum user name length.
For the NixOS assertion however, I use a maximum length of 31 to make
sure that nobody accidentally creates services that contain group names
that systemd considers invalid because of a length of 32 characters.
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #38548
Cc: @vcunat, @fpletz, @qknight
This GID was used to exempt users from Grsecurity's
`/proc` restrictions; we now prefer to rely on
`security.hideProcessInformation`, which uses the `proc` group
for this purpose. That leaves no use for the grsecurity GID.
More generally, having only a single GID to, presumably, serve as the
default for all of grsecurity's GID based exemption/resriction schemes
would be problematic in any event, so if we decide to enable those
grsecurity features in the future, more specific GIDs should be added.
Option aliases/deprecations can now be declared in any NixOS module,
not just in nixos/modules/rename.nix. This is more modular (since it
allows for example grub-related aliases to be declared in the grub
module), and allows aliases outside of NixOS (e.g. in NixOps modules).
The syntax is a bit funky. Ideally we'd have something like:
options = {
foo.bar.newOption = mkOption { ... };
foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ];
};
but that's not possible because options cannot define values in
*other* options - you need to have a "config" for that. So instead we
have functions that return a *module*: mkRemovedOptionModule,
mkRenamedOptionModule and mkAliasOptionModule. These can be used via
"imports", e.g.
imports = [
(mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]);
];
As an added bonus, deprecation warnings now show the file name of the
offending module.
Fixes#10385.
In this case, they're equivalent to setting ‘password’ and
‘hashedPassword’ (since there is no distinction between an initial and
non-initial user account state).
This hopefully fixes a regression introduced by 08b214a.
In bf129a2, it was already fixed for normal uid/gid values and it got
reintroduced by sub-uid/gid-handling again, so I've refactored it a bit
into a filterNull function which takes care of also the filtering
introduced by bf129a2.
I have not tested this extensively, but master is already broken for
systems with `mutableUsers = true` and no uid values set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With mutableUsers = true, we now ensure that all users and groups that
were created declaratively, are updated or removed
appropriately. Thus, adding a user to users.extraUsers and then
removing it now causes the acoount to be removed from
/etc/passwd. Thus user/group management is fully congruent except that
users and groups that were created imperatively (via useradd/groupadd)
are not touched. We distinguish between declarative and imperative
users/groups by tracking the former in
/var/lib/nixos/declarative-{groups,users}.
With mutableUsers = false, you are now no longer required to specify
UIDs/GIDs for all users. The handling of mutableUsers = true/false is
the same code path; the only difference is that the "false" mode
ignores the existing contents of /etc/{passwd,group}.
The attribute ‘createUser’ is gone. It doesn't really make sense to
specify users that shouldn't be created.
