nixpkgs/nixos/modules/config/users-groups.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

968 lines
34 KiB
Nix
Raw Normal View History

{ config, lib, utils, pkgs, ... }:
with lib;
let
ids = config.ids;
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
cfg = config.users;
# Check whether a password hash will allow login.
allowsLogin = hash:
hash == "" # login without password
|| !(lib.elem hash
[ null # password login disabled
"!" # password login disabled
"!!" # a variant of "!"
"*" # password unset
]);
passwordDescription = ''
The options {option}`hashedPassword`,
{option}`password` and {option}`hashedPasswordFile`
controls what password is set for the user.
{option}`hashedPassword` overrides both
{option}`password` and {option}`hashedPasswordFile`.
{option}`password` overrides {option}`hashedPasswordFile`.
If none of these three options are set, no password is assigned to
the user, and the user will not be able to do password logins.
If the option {option}`users.mutableUsers` is true, the
password defined in one of the three options will only be set when
the user is created for the first time. After that, you are free to
change the password with the ordinary user management commands. If
{option}`users.mutableUsers` is false, you cannot change
user passwords, they will always be set according to the password
options.
'';
hashedPasswordDescription = ''
To generate a hashed password run `mkpasswd`.
If set to an empty string (`""`), this user will
be able to log in without being asked for a password (but not via remote
services such as SSH, or indirectly via {command}`su` or
{command}`sudo`). This should only be used for e.g. bootable
live systems. Note: this is different from setting an empty password,
which can be achieved using {option}`users.users.<name?>.password`.
If set to `null` (default) this user will not
be able to log in using a password (i.e. via {command}`login`
command).
'';
userOpts = { name, config, ... }: {
options = {
name = mkOption {
type = types.passwdEntry types.str;
apply = x: assert (builtins.stringLength x < 32 || abort "Username '${x}' is longer than 31 characters which is not allowed!"); x;
description = ''
The name of the user account. If undefined, the name of the
attribute set will be used.
'';
};
description = mkOption {
type = types.passwdEntry types.str;
default = "";
example = "Alice Q. User";
description = ''
A short description of the user account, typically the
user's full name. This is actually the GECOS or comment
field in {file}`/etc/passwd`.
'';
};
uid = mkOption {
type = with types; nullOr int;
default = null;
description = ''
The account UID. If the UID is null, a free UID is picked on
activation.
'';
};
2014-04-29 10:43:38 +02:00
isSystemUser = mkOption {
type = types.bool;
default = false;
description = ''
Indicates if the user is a system user or not. This option
only has an effect if {option}`uid` is
2014-04-29 10:43:38 +02:00
{option}`null`, in which case it determines whether
the user's UID is allocated in the range for system users
(below 1000) or in the range for normal users (starting at
2014-04-29 10:43:38 +02:00
1000).
Exactly one of `isNormalUser` and
`isSystemUser` must be true.
2014-04-29 10:43:38 +02:00
'';
};
isNormalUser = mkOption {
type = types.bool;
default = false;
description = ''
Indicates whether this is an account for a real user.
This automatically sets {option}`group` to `users`,
{option}`createHome` to `true`,
{option}`home` to {file}`/home/«username»`,
{option}`useDefaultShell` to `true`,
and {option}`isSystemUser` to `false`.
Exactly one of `isNormalUser` and `isSystemUser` must be true.
'';
};
group = mkOption {
type = types.str;
Increase max group name length to 32 characters 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
2018-04-07 15:14:47 +02:00
apply = x: assert (builtins.stringLength x < 32 || abort "Group name '${x}' is longer than 31 characters which is not allowed!"); x;
default = "";
description = "The user's primary group.";
};
extraGroups = mkOption {
2013-10-30 17:37:45 +01:00
type = types.listOf types.str;
default = [];
description = "The user's auxiliary groups.";
};
home = mkOption {
type = types.passwdEntry types.path;
default = "/var/empty";
description = "The user's home directory.";
};
homeMode = mkOption {
type = types.strMatching "[0-7]{1,5}";
default = "700";
description = "The user's home directory mode in numeric format. See chmod(1). The mode is only applied if {option}`users.users.<name>.createHome` is true.";
};
cryptHomeLuks = mkOption {
type = with types; nullOr str;
default = null;
description = ''
Path to encrypted luks device that contains
the user's home directory.
'';
};
pamMount = mkOption {
type = with types; attrsOf str;
default = {};
description = ''
Attributes for user's entry in
{file}`pam_mount.conf.xml`.
Useful attributes might include `path`,
`options`, `fstype`, and `server`.
See <https://pam-mount.sourceforge.net/pam_mount.conf.5.html>
for more information.
'';
};
shell = mkOption {
type = types.nullOr (types.either types.shellPackage (types.passwdEntry types.path));
2018-07-23 01:52:54 +02:00
default = pkgs.shadow;
defaultText = literalExpression "pkgs.shadow";
example = literalExpression "pkgs.bashInteractive";
description = ''
The path to the user's shell. Can use shell derivations,
like `pkgs.bashInteractive`. Dont
forget to enable your shell in
`programs` if necessary,
like `programs.zsh.enable = true;`.
'';
};
ignoreShellProgramCheck = mkOption {
type = types.bool;
default = false;
description = ''
By default, nixos will check that programs.SHELL.enable is set to
true if the user has a custom shell specified. If that behavior isn't
required and there are custom overrides in place to make sure that the
shell is functional, set this to true.
'';
};
subUidRanges = mkOption {
type = with types; listOf (submodule subordinateUidRange);
default = [];
example = [
{ startUid = 1000; count = 1; }
{ startUid = 100001; count = 65534; }
];
description = ''
Subordinate user ids that user is allowed to use.
They are set into {file}`/etc/subuid` and are used
by `newuidmap` for user namespaces.
'';
};
subGidRanges = mkOption {
type = with types; listOf (submodule subordinateGidRange);
default = [];
example = [
{ startGid = 100; count = 1; }
{ startGid = 1001; count = 999; }
];
description = ''
Subordinate group ids that user is allowed to use.
They are set into {file}`/etc/subgid` and are used
by `newgidmap` for user namespaces.
'';
};
autoSubUidGidRange = mkOption {
type = types.bool;
default = false;
example = true;
description = ''
Automatically allocate subordinate user and group ids for this user.
Allocated range is currently always of size 65536.
'';
};
createHome = mkOption {
type = types.bool;
default = false;
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
description = ''
Whether to create the home directory and ensure ownership as well as
permissions to match the user.
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
'';
};
useDefaultShell = mkOption {
type = types.bool;
default = false;
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
description = ''
If true, the user's shell will be set to
{option}`users.defaultUserShell`.
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
'';
};
hashedPassword = mkOption {
type = with types; nullOr (passwdEntry str);
default = null;
description = ''
Specifies the hashed password for the user.
${passwordDescription}
${hashedPasswordDescription}
'';
};
password = mkOption {
type = with types; nullOr str;
default = null;
description = ''
Specifies the (clear text) password for the user.
Warning: do not set confidential information here
because it is world-readable in the Nix store. This option
should only be used for public accounts.
${passwordDescription}
'';
};
hashedPasswordFile = mkOption {
type = with types; nullOr str;
default = cfg.users.${name}.passwordFile;
defaultText = literalExpression "null";
description = ''
The full path to a file that contains the hash of the user's
password. The password file is read on each system activation. The
file should contain exactly one line, which should be the password in
an encrypted form that is suitable for the `chpasswd -e` command.
${passwordDescription}
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
'';
};
passwordFile = mkOption {
2023-09-13 11:43:19 +02:00
type = with types; nullOr str;
default = null;
visible = false;
description = "Deprecated alias of hashedPasswordFile";
};
initialHashedPassword = mkOption {
type = with types; nullOr (passwdEntry str);
default = null;
description = ''
Specifies the initial hashed password for the user, i.e. the
hashed password assigned if the user does not already
exist. If {option}`users.mutableUsers` is true, the
password can be changed subsequently using the
{command}`passwd` command. Otherwise, it's
equivalent to setting the {option}`hashedPassword` option.
Note that the {option}`hashedPassword` option will override
this option if both are set.
${hashedPasswordDescription}
'';
};
initialPassword = mkOption {
type = with types; nullOr str;
default = null;
description = ''
Specifies the initial password for the user, i.e. the
password assigned if the user does not already exist. If
{option}`users.mutableUsers` is true, the password
can be changed subsequently using the
{command}`passwd` command. Otherwise, it's
equivalent to setting the {option}`password`
option. The same caveat applies: the password specified here
is world-readable in the Nix store, so it should only be
used for guest accounts or passwords that will be changed
promptly.
Note that the {option}`password` option will override this
option if both are set.
'';
};
packages = mkOption {
type = types.listOf types.package;
default = [];
example = literalExpression "[ pkgs.firefox pkgs.thunderbird ]";
description = ''
The set of packages that should be made available to the user.
This is in contrast to {option}`environment.systemPackages`,
which adds packages to all users.
'';
};
expires = mkOption {
type = types.nullOr (types.strMatching "[[:digit:]]{4}-[[:digit:]]{2}-[[:digit:]]{2}");
default = null;
description = ''
Set the date on which the user's account will no longer be
accessible. The date is expressed in the format YYYY-MM-DD, or null
to disable the expiry.
A user whose account is locked must contact the system
administrator before being able to use the system again.
'';
};
linger = mkOption {
type = types.bool;
default = false;
description = ''
Whether to enable lingering for this user. If true, systemd user
units will start at boot, rather than starting at login and stopping
at logout. This is the declarative equivalent of running
`loginctl enable-linger` for this user.
If false, user units will not be started until the user logs in, and
may be stopped on logout depending on the settings in `logind.conf`.
'';
};
};
config = mkMerge
[ { name = mkDefault name;
shell = mkIf config.useDefaultShell (mkDefault cfg.defaultUserShell);
}
(mkIf config.isNormalUser {
group = mkDefault "users";
createHome = mkDefault true;
home = mkDefault "/home/${config.name}";
homeMode = mkDefault "700";
useDefaultShell = mkDefault true;
isSystemUser = mkDefault false;
})
# If !mutableUsers, setting initialPassword is equivalent to
# setting password (and similarly for hashed passwords).
(mkIf (!cfg.mutableUsers && config.initialPassword != null) {
password = mkDefault config.initialPassword;
})
(mkIf (!cfg.mutableUsers && config.initialHashedPassword != null) {
hashedPassword = mkDefault config.initialHashedPassword;
})
(mkIf (config.isNormalUser && config.subUidRanges == [] && config.subGidRanges == []) {
autoSubUidGidRange = mkDefault true;
})
];
};
groupOpts = { name, config, ... }: {
options = {
name = mkOption {
type = types.passwdEntry types.str;
description = ''
The name of the group. If undefined, the name of the attribute set
will be used.
'';
};
gid = mkOption {
type = with types; nullOr int;
default = null;
description = ''
The group GID. If the GID is null, a free GID is picked on
activation.
'';
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
};
members = mkOption {
type = with types; listOf (passwdEntry str);
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
default = [];
description = ''
The user names of the group members, added to the
`/etc/group` file.
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
'';
};
};
config = {
name = mkDefault name;
members = mapAttrsToList (n: u: u.name) (
filterAttrs (n: u: elem config.name u.extraGroups) cfg.users
);
};
};
subordinateUidRange = {
options = {
startUid = mkOption {
type = types.int;
description = ''
Start of the range of subordinate user ids that user is
allowed to use.
'';
};
count = mkOption {
type = types.int;
default = 1;
description = "Count of subordinate user ids";
};
};
};
subordinateGidRange = {
options = {
startGid = mkOption {
type = types.int;
description = ''
Start of the range of subordinate group ids that user is
allowed to use.
'';
};
count = mkOption {
type = types.int;
default = 1;
description = "Count of subordinate group ids";
};
};
};
2021-01-25 07:57:48 +01:00
idsAreUnique = set: idAttr: !(foldr (name: args@{ dup, acc }:
let
id = builtins.toString (builtins.getAttr idAttr (builtins.getAttr name set));
exists = builtins.hasAttr id acc;
newAcc = acc // (builtins.listToAttrs [ { name = id; value = true; } ]);
in if dup then args else if exists
then builtins.trace "Duplicate ${idAttr} ${id}" { dup = true; acc = null; }
else { dup = false; acc = newAcc; }
) { dup = false; acc = {}; } (builtins.attrNames set)).dup;
uidsAreUnique = idsAreUnique (filterAttrs (n: u: u.uid != null) cfg.users) "uid";
gidsAreUnique = idsAreUnique (filterAttrs (n: g: g.gid != null) cfg.groups) "gid";
sdInitrdUidsAreUnique = idsAreUnique (filterAttrs (n: u: u.uid != null) config.boot.initrd.systemd.users) "uid";
sdInitrdGidsAreUnique = idsAreUnique (filterAttrs (n: g: g.gid != null) config.boot.initrd.systemd.groups) "gid";
groupNames = lib.mapAttrsToList (n: g: g.name) cfg.groups;
usersWithoutExistingGroup = lib.filterAttrs (n: u: u.group != "" && !lib.elem u.group groupNames) cfg.users;
spec = pkgs.writeText "users-groups.json" (builtins.toJSON {
inherit (cfg) mutableUsers;
users = mapAttrsToList (_: u:
{ inherit (u)
name uid group description home homeMode createHome isSystemUser
password hashedPasswordFile hashedPassword
autoSubUidGidRange subUidRanges subGidRanges
initialPassword initialHashedPassword expires;
shell = utils.toShellPath u.shell;
}) cfg.users;
groups = attrValues cfg.groups;
});
systemShells =
let
shells = mapAttrsToList (_: u: u.shell) cfg.users;
in
filter types.shellPackage.check shells;
lingeringUsers = map (u: u.name) (attrValues (flip filterAttrs cfg.users (n: u: u.linger)));
in {
imports = [
(mkAliasOptionModuleMD [ "users" "extraUsers" ] [ "users" "users" ])
(mkAliasOptionModuleMD [ "users" "extraGroups" ] [ "users" "groups" ])
(mkRenamedOptionModule ["security" "initialRootPassword"] ["users" "users" "root" "initialHashedPassword"])
];
###### interface
options = {
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
users.mutableUsers = mkOption {
type = types.bool;
default = true;
description = ''
If set to `true`, you are free to add new users and groups to the system
with the ordinary `useradd` and
`groupadd` commands. On system activation, the
existing contents of the `/etc/passwd` and
`/etc/group` files will be merged with the
contents generated from the `users.users` and
`users.groups` options.
The initial password for a user will be set
according to `users.users`, but existing passwords
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
will not be changed.
::: {.warning}
If set to `false`, the contents of the user and
group files will simply be replaced on system activation. This also
holds for the user passwords; all changed
passwords will be reset according to the
`users.users` configuration on activation.
:::
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
'';
};
users.enforceIdUniqueness = mkOption {
type = types.bool;
default = true;
description = ''
Whether to require that no two users/groups share the same uid/gid.
'';
};
users.users = mkOption {
default = {};
type = with types; attrsOf (submodule userOpts);
example = {
alice = {
uid = 1234;
description = "Alice Q. User";
home = "/home/alice";
createHome = true;
group = "users";
extraGroups = ["wheel"];
shell = "/bin/sh";
};
};
description = ''
Additional user accounts to be created automatically by the system.
This can also be used to set options for root.
'';
};
users.groups = mkOption {
default = {};
example =
{ students.gid = 1001;
hackers = { };
};
type = with types; attrsOf (submodule groupOpts);
description = ''
Additional groups to be created automatically by the system.
'';
};
users.allowNoPasswordLogin = mkOption {
type = types.bool;
default = false;
description = ''
Disable checking that at least the `root` user or a user in the `wheel` group can log in using
a password or an SSH key.
WARNING: enabling this can lock you out of your system. Enable this only if you know what are you doing.
'';
};
# systemd initrd
boot.initrd.systemd.users = mkOption {
description = ''
Users to include in initrd.
'';
default = {};
type = types.attrsOf (types.submodule ({ name, ... }: {
options.uid = mkOption {
type = types.int;
description = ''
ID of the user in initrd.
'';
defaultText = literalExpression "config.users.users.\${name}.uid";
default = cfg.users.${name}.uid;
};
options.group = mkOption {
type = types.singleLineStr;
description = ''
Group the user belongs to in initrd.
'';
defaultText = literalExpression "config.users.users.\${name}.group";
default = cfg.users.${name}.group;
};
options.shell = mkOption {
type = types.passwdEntry types.path;
description = ''
The path to the user's shell in initrd.
'';
default = "${pkgs.shadow}/bin/nologin";
defaultText = literalExpression "\${pkgs.shadow}/bin/nologin";
};
}));
};
boot.initrd.systemd.groups = mkOption {
description = ''
Groups to include in initrd.
'';
default = {};
type = types.attrsOf (types.submodule ({ name, ... }: {
options.gid = mkOption {
type = types.int;
description = ''
ID of the group in initrd.
'';
defaultText = literalExpression "config.users.groups.\${name}.gid";
default = cfg.groups.${name}.gid;
};
}));
};
};
###### implementation
config = let
cryptSchemeIdPatternGroup = "(${lib.concatStringsSep "|" pkgs.libxcrypt.enabledCryptSchemeIds})";
in {
users.users = {
root = {
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
uid = ids.uids.root;
description = "System administrator";
home = "/root";
2014-08-20 21:17:48 +02:00
shell = mkDefault cfg.defaultUserShell;
group = "root";
};
nobody = {
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
uid = ids.uids.nobody;
isSystemUser = true;
description = "Unprivileged account (don't use!)";
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
group = "nogroup";
};
};
users.groups = {
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
root.gid = ids.gids.root;
wheel.gid = ids.gids.wheel;
disk.gid = ids.gids.disk;
kmem.gid = ids.gids.kmem;
tty.gid = ids.gids.tty;
floppy.gid = ids.gids.floppy;
uucp.gid = ids.gids.uucp;
lp.gid = ids.gids.lp;
cdrom.gid = ids.gids.cdrom;
tape.gid = ids.gids.tape;
audio.gid = ids.gids.audio;
video.gid = ids.gids.video;
dialout.gid = ids.gids.dialout;
nogroup.gid = ids.gids.nogroup;
users.gid = ids.gids.users;
nixbld.gid = ids.gids.nixbld;
utmp.gid = ids.gids.utmp;
adm.gid = ids.gids.adm;
input.gid = ids.gids.input;
kvm.gid = ids.gids.kvm;
render.gid = ids.gids.render;
sgx.gid = ids.gids.sgx;
shadow.gid = ids.gids.shadow;
};
2023-11-19 23:16:14 +01:00
system.activationScripts.users = if !config.systemd.sysusers.enable then {
2021-09-03 17:21:36 +02:00
supportsDryActivation = true;
text = ''
install -m 0700 -d /root
install -m 0755 -d /home
${pkgs.perl.withPackages (p: [ p.FileSlurp p.JSON ])}/bin/perl \
-w ${./update-users-groups.pl} ${spec}
'';
2023-11-19 23:16:14 +01:00
} else ""; # keep around for backwards compatibility
systemd.services.linger-users = lib.mkIf ((builtins.length lingeringUsers) > 0) {
wantedBy = ["multi-user.target"];
after = ["systemd-logind.service"];
requires = ["systemd-logind.service"];
script = let
lingerDir = "/var/lib/systemd/linger";
lingeringUsersFile = builtins.toFile "lingering-users"
(concatStrings (map (s: "${s}\n")
(sort (a: b: a < b) lingeringUsers))); # this sorting is important for `comm` to work correctly
in ''
mkdir -vp ${lingerDir}
cd ${lingerDir}
2024-03-21 18:47:15 +01:00
for user in $(ls); do
if ! id "$user" >/dev/null; then
echo "Removing linger for missing user $user"
rm --force -- "$user"
fi
done
ls | sort | comm -3 -1 ${lingeringUsersFile} - | xargs -r ${pkgs.systemd}/bin/loginctl disable-linger
ls | sort | comm -3 -2 ${lingeringUsersFile} - | xargs -r ${pkgs.systemd}/bin/loginctl enable-linger
'';
serviceConfig.Type = "oneshot";
};
# Warn about user accounts with deprecated password hashing schemes
2023-11-19 23:16:14 +01:00
# This does not work when the users and groups are created by
# systemd-sysusers because the users are created too late then.
system.activationScripts.hashes = if !config.systemd.sysusers.enable then {
deps = [ "users" ];
text = ''
users=()
while IFS=: read -r user hash _; do
if [[ "$hash" = "$"* && ! "$hash" =~ ^\''$${cryptSchemeIdPatternGroup}\$ ]]; then
users+=("$user")
fi
done </etc/shadow
if (( "''${#users[@]}" )); then
echo "
WARNING: The following user accounts rely on password hashing algorithms
that have been removed. They need to be renewed as soon as possible, as
they do prevent their users from logging in."
printf ' - %s\n' "''${users[@]}"
fi
'';
2023-11-19 23:16:14 +01:00
} else ""; # keep around for backwards compatibility
Generate /etc/passwd and /etc/group at build time This is a rather large commit that switches user/group creation from using useradd/groupadd on activation to just generating the contents of /etc/passwd and /etc/group, and then on activation merging the generated files with the files that exist in the system. This makes the user activation process much cleaner, in my opinion. The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be properly defined (if <user>.createUser is true, which it is by default). My pull request adds a lot of uids/gids to config.ids to solve this problem for existing nixos services, but there might be configurations that break because this change. However, this will be discovered during the build. Option changes introduced by this commit: * Remove the options <user>.isSystemUser and <user>.isAlias since they don't make sense when generating /etc/passwd statically. * Add <group>.members as a complement to <user>.extraGroups. * Add <user>.passwordFile for setting a user's password from an encrypted (shadow-style) file. * Add users.mutableUsers which is true by default. This means you can keep managing your users as previously, by using useradd/groupadd manually. This is accomplished by merging the generated passwd/group file with the existing files in /etc on system activation. The merging of the files is simplistic. It just looks at the user/group names. If a user/group exists both on the system and in the generated files, the system entry will be kept un-changed and the generated entries will be ignored. The merging itself is performed with the help of vipw/vigr to properly lock the account files during edit. If mutableUsers is set to false, the generated passwd and group files will not be merged with the system files on activation. Instead they will simply replace the system files, and overwrite any changes done on the running system. The same logic holds for user password, if the <user>.password or <user>.passwordFile options are used. If mutableUsers is false, password will simply be replaced on activation. If true, the initial user passwords will be set according to the configuration, but existing passwords will not be touched. I have tested this on a couple of different systems and it seems to work fine so far. If you think this is a good idea, please test it. This way of adding local users has been discussed in issue #103 (and this commit solves that issue).
2013-05-17 17:08:32 +02:00
# for backwards compatibility
system.activationScripts.groups = stringAfter [ "users" ] "";
2018-03-20 23:40:57 +01:00
# Install all the user shells
environment.systemPackages = systemShells;
environment.etc = mapAttrs' (_: { packages, name, ... }: {
2018-03-20 23:40:57 +01:00
name = "profiles/per-user/${name}";
value.source = pkgs.buildEnv {
name = "user-environment";
paths = packages;
inherit (config.environment) pathsToLink extraOutputsToInstall;
inherit (config.system.path) ignoreCollisions postBuild;
};
}) (filterAttrs (_: u: u.packages != []) cfg.users);
2018-03-20 23:40:57 +01:00
environment.profiles = [
"$HOME/.nix-profile"
"\${XDG_STATE_HOME}/nix/profile"
"$HOME/.local/state/nix/profile"
"/etc/profiles/per-user/$USER"
];
# systemd initrd
boot.initrd.systemd = lib.mkIf config.boot.initrd.systemd.enable {
contents = {
"/etc/passwd".text = ''
${lib.concatStringsSep "\n" (lib.mapAttrsToList (n: { uid, group, shell }: let
g = config.boot.initrd.systemd.groups.${group};
in "${n}:x:${toString uid}:${toString g.gid}::/var/empty:${shell}") config.boot.initrd.systemd.users)}
'';
"/etc/group".text = ''
${lib.concatStringsSep "\n" (lib.mapAttrsToList (n: { gid }: "${n}:x:${toString gid}:") config.boot.initrd.systemd.groups)}
'';
"/etc/shells".text = lib.concatStringsSep "\n" (lib.unique (lib.mapAttrsToList (_: u: u.shell) config.boot.initrd.systemd.users)) + "\n";
};
storePaths = [ "${pkgs.shadow}/bin/nologin" ];
users = {
root = { shell = lib.mkDefault "/bin/bash"; };
nobody = {};
};
groups = {
root = {};
nogroup = {};
systemd-journal = {};
tty = {};
dialout = {};
kmem = {};
input = {};
video = {};
render = {};
sgx = {};
audio = {};
video = {};
lp = {};
disk = {};
cdrom = {};
tape = {};
kvm = {};
};
};
assertions = [
{ assertion = !cfg.enforceIdUniqueness || (uidsAreUnique && gidsAreUnique);
message = "UIDs and GIDs must be unique!";
}
{ assertion = !cfg.enforceIdUniqueness || (sdInitrdUidsAreUnique && sdInitrdGidsAreUnique);
message = "systemd initrd UIDs and GIDs must be unique!";
}
{ assertion = usersWithoutExistingGroup == {};
message =
let
errUsers = lib.attrNames usersWithoutExistingGroup;
missingGroups = lib.unique (lib.mapAttrsToList (n: u: u.group) usersWithoutExistingGroup);
mkConfigHint = group: "users.groups.${group} = {};";
in ''
The following users have a primary group that is undefined: ${lib.concatStringsSep " " errUsers}
Hint: Add this to your NixOS configuration:
${lib.concatStringsSep "\n " (map mkConfigHint missingGroups)}
'';
}
{ # If mutableUsers is false, to prevent users creating a
# configuration that locks them out of the system, ensure that
# there is at least one "privileged" account that has a
# password or an SSH authorized key. Privileged accounts are
# root and users in the wheel group.
# The check does not apply when users.disableLoginPossibilityAssertion
# The check does not apply when users.mutableUsers
assertion = !cfg.mutableUsers -> !cfg.allowNoPasswordLogin ->
any id (mapAttrsToList (name: cfg:
(name == "root"
|| cfg.group == "wheel"
|| elem "wheel" cfg.extraGroups)
&&
(allowsLogin cfg.hashedPassword
|| cfg.password != null
|| cfg.hashedPasswordFile != null
|| cfg.openssh.authorizedKeys.keys != []
|| cfg.openssh.authorizedKeys.keyFiles != [])
) cfg.users ++ [
config.security.googleOsLogin.enable
]);
message = ''
Neither the root account nor any wheel user has a password or SSH authorized key.
You must set one to prevent being locked out of your system.
If you really want to be locked out of your system, set users.allowNoPasswordLogin = true;
However you are most probably better off by setting users.mutableUsers = true; and
manually running passwd root to set the root password.
'';
}
] ++ flatten (flip mapAttrsToList cfg.users (name: user:
[
{
assertion = (user.hashedPassword != null)
-> (builtins.match ".*:.*" user.hashedPassword == null);
message = ''
The password hash of user "${user.name}" contains a ":" character.
This is invalid and would break the login system because the fields
of /etc/shadow (file where hashes are stored) are colon-separated.
Please check the value of option `users.users."${user.name}".hashedPassword`.'';
}
{
assertion = let
isEffectivelySystemUser = user.isSystemUser || (user.uid != null && user.uid < 1000);
in xor isEffectivelySystemUser user.isNormalUser;
message = ''
Exactly one of users.users.${user.name}.isSystemUser and users.users.${user.name}.isNormalUser must be set.
'';
}
{
assertion = user.group != "";
message = ''
users.users.${user.name}.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.${user.name}.group = "${user.name}";
users.groups.${user.name} = {};
'';
}
2023-01-19 17:59:11 +01:00
] ++ (map (shell: {
assertion = !user.ignoreShellProgramCheck -> (user.shell == pkgs.${shell}) -> (config.programs.${shell}.enable == true);
message = ''
2023-01-19 17:59:11 +01:00
users.users.${user.name}.shell is set to ${shell}, but
programs.${shell}.enable is not true. This will cause the ${shell}
shell to lack the basic nix directories in its PATH and might make
logging in as that user impossible. You can fix it with:
2023-01-19 17:59:11 +01:00
programs.${shell}.enable = true;
If you know what you're doing and you are fine with the behavior,
set users.users.${user.name}.ignoreShellProgramCheck = true;
instead.
'';
2023-01-19 17:59:11 +01:00
}) [
"fish"
"xonsh"
"zsh"
])
));
2020-03-23 02:13:02 +01:00
warnings =
flip concatMap (attrValues cfg.users) (user: let
unambiguousPasswordConfiguration = 1 >= length (filter (x: x != null) ([
user.hashedPassword
user.hashedPasswordFile
user.password
] ++ optionals cfg.mutableUsers [
# For immutable users, initialHashedPassword is set to hashedPassword,
# so using these options would always trigger the assertion.
user.initialHashedPassword
user.initialPassword
]));
in optional (!unambiguousPasswordConfiguration) ''
The user '${user.name}' has multiple of the options
`hashedPassword`, `password`, `hashedPasswordFile`, `initialPassword`
& `initialHashedPassword` set to a non-null value.
The options silently discard others by the order of precedence
given above which can lead to surprising results. To resolve this warning,
set at most one of the options above to a non-`null` value.
'')
++ builtins.filter (x: x != null) (
flip mapAttrsToList cfg.users (_: user:
2020-03-23 02:13:02 +01:00
# This regex matches a subset of the Modular Crypto Format (MCF)[1]
# informal standard. Since this depends largely on the OS or the
# specific implementation of crypt(3) we only support the (sane)
# schemes implemented by glibc and BSDs. In particular the original
# DES hash is excluded since, having no structure, it would validate
# common mistakes like typing the plaintext password.
#
# [1]: https://en.wikipedia.org/wiki/Crypt_(C)
let
sep = "\\$";
base64 = "[a-zA-Z0-9./]+";
id = cryptSchemeIdPatternGroup;
name = "[a-z0-9-]+";
2020-03-23 02:13:02 +01:00
value = "[a-zA-Z0-9/+.-]+";
options = "${name}(=${value})?(,${name}=${value})*";
2020-03-23 02:13:02 +01:00
scheme = "${id}(${sep}${options})?";
content = "${base64}${sep}${base64}(${sep}${base64})?";
2020-03-23 02:13:02 +01:00
mcf = "^${sep}${scheme}${sep}${content}$";
in
if (allowsLogin user.hashedPassword
&& user.hashedPassword != "" # login without password
2020-03-23 02:13:02 +01:00
&& builtins.match mcf user.hashedPassword == null)
then ''
The password hash of user "${user.name}" may be invalid. You must set a
valid hash or the user will be locked out of their account. Please
check the value of option `users.users."${user.name}".hashedPassword`.''
else null)
++ flip mapAttrsToList cfg.users (name: user:
if user.passwordFile != null then
''The option `users.users."${name}".passwordFile' has been renamed '' +
''to `users.users."${name}".hashedPasswordFile'.''
else null)
);
};
}