2016-06-12 21:03:14 +02:00
|
|
|
|
{ config, lib, utils, pkgs, ... }:
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2014-04-14 16:26:48 +02:00
|
|
|
|
with lib;
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
|
|
|
|
let
|
2009-05-29 16:25:56 +02:00
|
|
|
|
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;
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2020-06-25 02:02:29 +02:00
|
|
|
|
# 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
|
|
|
|
|
]);
|
|
|
|
|
|
2014-02-05 15:07:20 +01:00
|
|
|
|
passwordDescription = ''
|
2014-11-03 11:59:38 +01:00
|
|
|
|
The options <option>hashedPassword</option>,
|
|
|
|
|
<option>password</option> and <option>passwordFile</option>
|
2014-02-05 15:07:20 +01:00
|
|
|
|
controls what password is set for the user.
|
2014-11-03 11:59:38 +01:00
|
|
|
|
<option>hashedPassword</option> overrides both
|
|
|
|
|
<option>password</option> and <option>passwordFile</option>.
|
|
|
|
|
<option>password</option> overrides <option>passwordFile</option>.
|
2014-02-05 15:07:20 +01:00
|
|
|
|
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.
|
2014-11-03 11:59:38 +01:00
|
|
|
|
If the option <option>users.mutableUsers</option> is true, the
|
2014-02-05 15:07:20 +01:00
|
|
|
|
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
|
2014-11-03 11:59:38 +01:00
|
|
|
|
<option>users.mutableUsers</option> is false, you cannot change
|
2014-02-05 15:07:20 +01:00
|
|
|
|
user passwords, they will always be set according to the password
|
|
|
|
|
options.
|
|
|
|
|
'';
|
|
|
|
|
|
2015-01-02 17:32:33 +01:00
|
|
|
|
hashedPasswordDescription = ''
|
2020-10-26 03:22:17 +01:00
|
|
|
|
To generate a hashed password run <literal>mkpasswd -m sha-512</literal>.
|
2020-07-04 02:05:03 +02:00
|
|
|
|
|
2020-06-21 16:55:45 +02:00
|
|
|
|
If set to an empty string (<literal>""</literal>), 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</command> or
|
|
|
|
|
<command>sudo</command>). This should only be used for e.g. bootable
|
|
|
|
|
live systems. Note: this is different from setting an empty password,
|
|
|
|
|
which ca be achieved using <option>users.users.<name?>.password</option>.
|
2020-07-04 02:05:03 +02:00
|
|
|
|
|
2020-06-21 16:55:45 +02:00
|
|
|
|
If set to <literal>null</literal> (default) this user will not
|
|
|
|
|
be able to log in using a password (i.e. via <command>login</command>
|
|
|
|
|
command).
|
2015-01-02 17:32:33 +01:00
|
|
|
|
'';
|
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
userOpts = { name, config, ... }: {
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
options = {
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
name = mkOption {
|
2013-10-30 11:02:04 +01:00
|
|
|
|
type = types.str;
|
2018-03-08 20:46:11 +01:00
|
|
|
|
apply = x: assert (builtins.stringLength x < 32 || abort "Username '${x}' is longer than 31 characters which is not allowed!"); x;
|
2014-04-06 12:39:51 +02:00
|
|
|
|
description = ''
|
|
|
|
|
The name of the user account. If undefined, the name of the
|
|
|
|
|
attribute set will be used.
|
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
description = mkOption {
|
2013-10-30 11:02:04 +01:00
|
|
|
|
type = types.str;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = "";
|
2013-10-31 08:41:51 +01:00
|
|
|
|
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 <filename>/etc/passwd</filename>.
|
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
uid = mkOption {
|
2014-04-06 12:39:51 +02:00
|
|
|
|
type = with types; nullOr int;
|
|
|
|
|
default = null;
|
|
|
|
|
description = ''
|
2014-08-15 01:33:20 +02:00
|
|
|
|
The account UID. If the UID is null, a free UID is picked on
|
|
|
|
|
activation.
|
2014-04-06 12:39:51 +02:00
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
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
|
2014-08-15 01:33:20 +02:00
|
|
|
|
only has an effect if <option>uid</option> is
|
2014-04-29 10:43:38 +02:00
|
|
|
|
<option>null</option>, in which case it determines whether
|
|
|
|
|
the user's UID is allocated in the range for system users
|
|
|
|
|
(below 500) or in the range for normal users (starting at
|
|
|
|
|
1000).
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2014-08-15 02:07:43 +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</option> to
|
|
|
|
|
<literal>users</literal>, <option>createHome</option> to
|
|
|
|
|
<literal>true</literal>, <option>home</option> to
|
|
|
|
|
<filename>/home/<replaceable>username</replaceable></filename>,
|
|
|
|
|
<option>useDefaultShell</option> to <literal>true</literal>,
|
|
|
|
|
and <option>isSystemUser</option> to
|
|
|
|
|
<literal>false</literal>.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
group = mkOption {
|
2013-10-30 11:02:04 +01:00
|
|
|
|
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;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = "nogroup";
|
|
|
|
|
description = "The user's primary group.";
|
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
extraGroups = mkOption {
|
2013-10-30 17:37:45 +01:00
|
|
|
|
type = types.listOf types.str;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = [];
|
|
|
|
|
description = "The user's auxiliary groups.";
|
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
home = mkOption {
|
2016-06-12 21:03:14 +02:00
|
|
|
|
type = types.path;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = "/var/empty";
|
|
|
|
|
description = "The user's home directory.";
|
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2015-07-02 16:46:56 +02:00
|
|
|
|
cryptHomeLuks = mkOption {
|
|
|
|
|
type = with types; nullOr str;
|
|
|
|
|
default = null;
|
|
|
|
|
description = ''
|
|
|
|
|
Path to encrypted luks device that contains
|
|
|
|
|
the user's home directory.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-15 02:29:30 +02:00
|
|
|
|
pamMount = mkOption {
|
|
|
|
|
type = with types; attrsOf str;
|
|
|
|
|
default = {};
|
|
|
|
|
description = ''
|
|
|
|
|
Attributes for user's entry in
|
|
|
|
|
<filename>pam_mount.conf.xml</filename>.
|
|
|
|
|
Useful attributes might include <code>path</code>,
|
|
|
|
|
<code>options</code>, <code>fstype</code>, and <code>server</code>.
|
|
|
|
|
See <link
|
|
|
|
|
xlink:href="http://pam-mount.sourceforge.net/pam_mount.conf.5.html" />
|
|
|
|
|
for more information.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
shell = mkOption {
|
2018-06-04 06:01:53 +02:00
|
|
|
|
type = types.nullOr (types.either types.shellPackage types.path);
|
2018-07-23 01:52:54 +02:00
|
|
|
|
default = pkgs.shadow;
|
|
|
|
|
defaultText = "pkgs.shadow";
|
2016-06-12 21:03:14 +02:00
|
|
|
|
example = literalExample "pkgs.bashInteractive";
|
2016-03-08 18:02:15 +01:00
|
|
|
|
description = ''
|
|
|
|
|
The path to the user's shell. Can use shell derivations,
|
|
|
|
|
like <literal>pkgs.bashInteractive</literal>. Don’t
|
|
|
|
|
forget to enable your shell in
|
|
|
|
|
<literal>programs</literal> if necessary,
|
|
|
|
|
like <code>programs.zsh.enable = true;</code>.
|
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2014-06-26 02:11:28 +02:00
|
|
|
|
subUidRanges = mkOption {
|
2016-09-11 09:35:50 +02:00
|
|
|
|
type = with types; listOf (submodule subordinateUidRange);
|
2014-06-26 02:11:28 +02:00
|
|
|
|
default = [];
|
|
|
|
|
example = [
|
|
|
|
|
{ startUid = 1000; count = 1; }
|
|
|
|
|
{ startUid = 100001; count = 65534; }
|
|
|
|
|
];
|
|
|
|
|
description = ''
|
|
|
|
|
Subordinate user ids that user is allowed to use.
|
|
|
|
|
They are set into <filename>/etc/subuid</filename> and are used
|
|
|
|
|
by <literal>newuidmap</literal> for user namespaces.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
subGidRanges = mkOption {
|
2016-09-11 09:35:50 +02:00
|
|
|
|
type = with types; listOf (submodule subordinateGidRange);
|
2014-06-26 02:11:28 +02:00
|
|
|
|
default = [];
|
|
|
|
|
example = [
|
|
|
|
|
{ startGid = 100; count = 1; }
|
|
|
|
|
{ startGid = 1001; count = 999; }
|
|
|
|
|
];
|
|
|
|
|
description = ''
|
|
|
|
|
Subordinate group ids that user is allowed to use.
|
|
|
|
|
They are set into <filename>/etc/subgid</filename> and are used
|
|
|
|
|
by <literal>newgidmap</literal> for user namespaces.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
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 = ''
|
nixos/users-groups: createHome: Ensure HOME permissions, fix description
configuration.nix(1) states
users.extraUsers.<name>.createHome
[...] If [...] the home directory already exists but is not
owned by the user, directory owner and group will be changed to
match the user.
i.e. ownership would change only if the user mismatched; the code
however ignores the owner, it is sufficient to enable `createHome`:
if ($u->{createHome}) {
make_path($u->{home}, { mode => 0700 }) if ! -e $u->{home};
chown $u->{uid}, $u->{gid}, $u->{home};
}
Furthermore, permissions are ignored on already existing directories and
therefore may allow others to read private data eventually.
Given that createHome already acts as switch to not only create but
effectively own the home directory, manage permissions in the same
manner to ensure the intended default and cover all primary attributes.
Avoid yet another configuration option to have administrators make a
clear and simple choice between securely managing home directories
and optionally defering management to own code (taking care of custom
location, ownership, mode, extended attributes, etc.).
While here, simplify and thereby fix misleading documentation.
2020-11-22 23:42:02 +01:00
|
|
|
|
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
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01: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
|
2014-11-03 11:59:38 +01:00
|
|
|
|
<option>users.defaultUserShell</option>.
|
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
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2014-02-05 15:07:20 +01:00
|
|
|
|
hashedPassword = mkOption {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; nullOr str;
|
2014-02-05 15:07:20 +01:00
|
|
|
|
default = null;
|
|
|
|
|
description = ''
|
2014-11-03 11:59:38 +01:00
|
|
|
|
Specifies the hashed password for the user.
|
2014-02-05 15:07:20 +01:00
|
|
|
|
${passwordDescription}
|
2015-01-02 17:32:33 +01:00
|
|
|
|
${hashedPasswordDescription}
|
2014-02-05 15:07:20 +01:00
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
password = mkOption {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; nullOr str;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = null;
|
2013-10-31 08:41:51 +01:00
|
|
|
|
description = ''
|
2014-02-05 15:07:20 +01:00
|
|
|
|
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}
|
2013-10-31 08:41:51 +01:00
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
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 {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; nullOr 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 = null;
|
|
|
|
|
description = ''
|
2014-10-23 04:52:50 +02:00
|
|
|
|
The full path to a file that contains the user's password. The password
|
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
|
|
|
|
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 <literal>chpasswd -e</literal> command.
|
2014-02-05 15:07:20 +01:00
|
|
|
|
${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
|
|
|
|
'';
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2014-11-03 11:59:38 +01:00
|
|
|
|
|
|
|
|
|
initialHashedPassword = mkOption {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; nullOr str;
|
2014-11-03 11:59:38 +01:00
|
|
|
|
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</option> is true, the
|
|
|
|
|
password can be changed subsequently using the
|
|
|
|
|
<command>passwd</command> command. Otherwise, it's
|
2015-09-02 16:09:05 +02:00
|
|
|
|
equivalent to setting the <option>hashedPassword</option> option.
|
2015-01-02 17:32:33 +01:00
|
|
|
|
|
|
|
|
|
${hashedPasswordDescription}
|
2014-11-03 11:59:38 +01:00
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
initialPassword = mkOption {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; nullOr str;
|
2014-11-03 11:59:38 +01:00
|
|
|
|
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</option> is true, the password
|
|
|
|
|
can be changed subsequently using the
|
|
|
|
|
<command>passwd</command> command. Otherwise, it's
|
|
|
|
|
equivalent to setting the <option>password</option>
|
|
|
|
|
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.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2017-05-11 20:31:06 +02:00
|
|
|
|
packages = mkOption {
|
|
|
|
|
type = types.listOf types.package;
|
|
|
|
|
default = [];
|
|
|
|
|
example = literalExample "[ pkgs.firefox pkgs.thunderbird ]";
|
|
|
|
|
description = ''
|
2019-10-22 21:58:09 +02:00
|
|
|
|
The set of packages that should be made available to the user.
|
2017-05-11 20:31:06 +02:00
|
|
|
|
This is in contrast to <option>environment.systemPackages</option>,
|
|
|
|
|
which adds packages to all users.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2014-08-15 02:07:43 +02:00
|
|
|
|
config = mkMerge
|
|
|
|
|
[ { name = mkDefault name;
|
|
|
|
|
shell = mkIf config.useDefaultShell (mkDefault cfg.defaultUserShell);
|
|
|
|
|
}
|
|
|
|
|
(mkIf config.isNormalUser {
|
|
|
|
|
group = mkDefault "users";
|
|
|
|
|
createHome = mkDefault true;
|
2018-10-24 19:38:56 +02:00
|
|
|
|
home = mkDefault "/home/${config.name}";
|
2014-08-15 02:07:43 +02:00
|
|
|
|
useDefaultShell = mkDefault true;
|
|
|
|
|
isSystemUser = mkDefault false;
|
|
|
|
|
})
|
2014-11-03 12:19:25 +01:00
|
|
|
|
# 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;
|
|
|
|
|
})
|
2014-08-15 02:07:43 +02:00
|
|
|
|
];
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2018-07-20 22:56:59 +02:00
|
|
|
|
groupOpts = { name, ... }: {
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
options = {
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
name = mkOption {
|
2013-10-30 11:02:04 +01:00
|
|
|
|
type = types.str;
|
2014-04-06 12:39:51 +02:00
|
|
|
|
description = ''
|
|
|
|
|
The name of the group. If undefined, the name of the attribute set
|
|
|
|
|
will be used.
|
|
|
|
|
'';
|
2012-04-20 14:55:09 +02:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
gid = mkOption {
|
2014-04-06 12:39:51 +02:00
|
|
|
|
type = with types; nullOr int;
|
|
|
|
|
default = null;
|
|
|
|
|
description = ''
|
2014-08-15 01:33:20 +02:00
|
|
|
|
The group GID. If the GID is null, a free GID is picked on
|
|
|
|
|
activation.
|
2014-04-06 12:39:51 +02:00
|
|
|
|
'';
|
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 {
|
2019-08-08 22:48:27 +02:00
|
|
|
|
type = with types; listOf 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 = ''
|
2014-02-05 15:24:05 +01:00
|
|
|
|
The user names of the group members, added to the
|
|
|
|
|
<literal>/etc/group</literal> 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
|
|
|
|
'';
|
2012-04-20 14:55:09 +02:00
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
};
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
config = {
|
|
|
|
|
name = mkDefault name;
|
|
|
|
|
};
|
2012-10-23 13:35:06 +02:00
|
|
|
|
|
2012-04-20 14:55:09 +02:00
|
|
|
|
};
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
2014-06-26 02:11:28 +02:00
|
|
|
|
subordinateUidRange = {
|
2016-09-11 09:35:50 +02:00
|
|
|
|
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;
|
2021-01-24 10:19:10 +01:00
|
|
|
|
description = "Count of subordinate user ids";
|
2016-09-11 09:35:50 +02:00
|
|
|
|
};
|
2014-06-26 02:11:28 +02:00
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
subordinateGidRange = {
|
2016-09-11 09:35:50 +02:00
|
|
|
|
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;
|
2021-01-24 10:19:10 +01:00
|
|
|
|
description = "Count of subordinate group ids";
|
2016-09-11 09:35:50 +02:00
|
|
|
|
};
|
2014-06-26 02:11:28 +02:00
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2014-02-07 15:57:28 +01:00
|
|
|
|
idsAreUnique = set: idAttr: !(fold (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;
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
2015-09-02 17:32:38 +02:00
|
|
|
|
uidsAreUnique = idsAreUnique (filterAttrs (n: u: u.uid != null) cfg.users) "uid";
|
|
|
|
|
gidsAreUnique = idsAreUnique (filterAttrs (n: g: g.gid != null) cfg.groups) "gid";
|
2014-04-06 12:39:51 +02:00
|
|
|
|
|
2014-09-10 11:49:32 +02:00
|
|
|
|
spec = pkgs.writeText "users-groups.json" (builtins.toJSON {
|
2014-08-15 01:33:20 +02:00
|
|
|
|
inherit (cfg) mutableUsers;
|
2016-06-12 21:03:14 +02:00
|
|
|
|
users = mapAttrsToList (_: u:
|
2014-08-15 01:33:20 +02:00
|
|
|
|
{ inherit (u)
|
2016-06-12 21:03:14 +02:00
|
|
|
|
name uid group description home createHome isSystemUser
|
2014-11-03 11:59:38 +01:00
|
|
|
|
password passwordFile hashedPassword
|
2020-04-28 23:30:34 +02:00
|
|
|
|
isNormalUser subUidRanges subGidRanges
|
2014-11-03 11:59:38 +01:00
|
|
|
|
initialPassword initialHashedPassword;
|
2016-06-12 21:03:14 +02:00
|
|
|
|
shell = utils.toShellPath u.shell;
|
2015-09-02 17:32:38 +02:00
|
|
|
|
}) cfg.users;
|
2014-08-15 01:33:20 +02:00
|
|
|
|
groups = mapAttrsToList (n: g:
|
|
|
|
|
{ inherit (g) name gid;
|
2014-09-22 19:18:08 +02:00
|
|
|
|
members = g.members ++ (mapAttrsToList (n: u: u.name) (
|
2015-09-02 17:32:38 +02:00
|
|
|
|
filterAttrs (n: u: elem g.name u.extraGroups) cfg.users
|
2014-09-22 19:18:08 +02:00
|
|
|
|
));
|
2015-09-02 17:32:38 +02:00
|
|
|
|
}) cfg.groups;
|
2014-08-15 01:33:20 +02:00
|
|
|
|
});
|
|
|
|
|
|
2016-06-12 21:03:14 +02:00
|
|
|
|
systemShells =
|
|
|
|
|
let
|
|
|
|
|
shells = mapAttrsToList (_: u: u.shell) cfg.users;
|
|
|
|
|
in
|
|
|
|
|
filter types.shellPackage.check shells;
|
|
|
|
|
|
2014-04-06 12:39:51 +02:00
|
|
|
|
in {
|
2019-12-10 02:51:19 +01:00
|
|
|
|
imports = [
|
|
|
|
|
(mkAliasOptionModule [ "users" "extraUsers" ] [ "users" "users" ])
|
|
|
|
|
(mkAliasOptionModule [ "users" "extraGroups" ] [ "users" "groups" ])
|
2020-06-21 15:28:54 +02:00
|
|
|
|
(mkChangedOptionModule
|
|
|
|
|
[ "security" "initialRootPassword" ]
|
|
|
|
|
[ "users" "users" "root" "initialHashedPassword" ]
|
2020-07-11 15:48:26 +02:00
|
|
|
|
(cfg: if cfg.security.initialRootPassword == "!"
|
2020-06-21 15:28:54 +02:00
|
|
|
|
then null
|
2020-07-11 15:48:26 +02:00
|
|
|
|
else cfg.security.initialRootPassword))
|
2019-12-10 02:51:19 +01:00
|
|
|
|
];
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
2009-09-02 19:35:24 +02:00
|
|
|
|
###### interface
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
2009-09-02 19:35:24 +02:00
|
|
|
|
options = {
|
2011-09-14 20:20:50 +02:00
|
|
|
|
|
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 = ''
|
2015-01-02 17:32:33 +01:00
|
|
|
|
If set to <literal>true</literal>, you are free to add new users and groups to the system
|
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
|
|
|
|
with the ordinary <literal>useradd</literal> and
|
|
|
|
|
<literal>groupadd</literal> commands. On system activation, the
|
|
|
|
|
existing contents of the <literal>/etc/passwd</literal> and
|
|
|
|
|
<literal>/etc/group</literal> files will be merged with the
|
2015-09-02 17:32:38 +02:00
|
|
|
|
contents generated from the <literal>users.users</literal> and
|
|
|
|
|
<literal>users.groups</literal> options.
|
2015-01-02 17:32:33 +01:00
|
|
|
|
The initial password for a user will be set
|
2015-09-02 17:32:38 +02:00
|
|
|
|
according to <literal>users.users</literal>, 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.
|
2015-01-02 17:32:33 +01:00
|
|
|
|
|
2015-01-03 16:32:00 +01:00
|
|
|
|
<warning><para>
|
2015-01-02 17:32:33 +01:00
|
|
|
|
If set to <literal>false</literal>, 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
|
2015-09-02 17:32:38 +02:00
|
|
|
|
<literal>users.users</literal> configuration on activation.
|
2015-01-03 16:32:00 +01:00
|
|
|
|
</para></warning>
|
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
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2014-02-07 15:57:28 +01:00
|
|
|
|
users.enforceIdUniqueness = mkOption {
|
|
|
|
|
type = types.bool;
|
|
|
|
|
default = true;
|
|
|
|
|
description = ''
|
|
|
|
|
Whether to require that no two users/groups share the same uid/gid.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2015-09-02 17:32:38 +02:00
|
|
|
|
users.users = mkOption {
|
2011-11-29 07:08:55 +01:00
|
|
|
|
default = {};
|
2020-08-23 01:28:45 +02:00
|
|
|
|
type = with types; attrsOf (submodule userOpts);
|
2011-11-29 07:08:55 +01:00
|
|
|
|
example = {
|
|
|
|
|
alice = {
|
|
|
|
|
uid = 1234;
|
2013-10-31 08:41:51 +01:00
|
|
|
|
description = "Alice Q. User";
|
2011-11-29 07:08:55 +01:00
|
|
|
|
home = "/home/alice";
|
|
|
|
|
createHome = true;
|
|
|
|
|
group = "users";
|
|
|
|
|
extraGroups = ["wheel"];
|
|
|
|
|
shell = "/bin/sh";
|
|
|
|
|
};
|
|
|
|
|
};
|
2009-09-02 19:35:24 +02:00
|
|
|
|
description = ''
|
|
|
|
|
Additional user accounts to be created automatically by the system.
|
2013-08-09 03:23:22 +02:00
|
|
|
|
This can also be used to set options for root.
|
2009-09-02 19:35:24 +02:00
|
|
|
|
'';
|
|
|
|
|
};
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
2015-09-02 17:32:38 +02:00
|
|
|
|
users.groups = mkOption {
|
2012-04-20 14:55:09 +02:00
|
|
|
|
default = {};
|
2009-09-02 19:35:24 +02:00
|
|
|
|
example =
|
2012-04-20 14:55:09 +02:00
|
|
|
|
{ students.gid = 1001;
|
|
|
|
|
hackers = { };
|
|
|
|
|
};
|
2020-08-23 01:28:45 +02:00
|
|
|
|
type = with types; attrsOf (submodule groupOpts);
|
2009-09-02 19:35:24 +02:00
|
|
|
|
description = ''
|
|
|
|
|
Additional groups to be created automatically by the system.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
};
|
2011-09-14 20:20:50 +02:00
|
|
|
|
|
2009-09-02 19:35:24 +02:00
|
|
|
|
|
|
|
|
|
###### implementation
|
|
|
|
|
|
|
|
|
|
config = {
|
|
|
|
|
|
2015-09-02 17:32:38 +02:00
|
|
|
|
users.users = {
|
2011-11-29 07:08:55 +01:00
|
|
|
|
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;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
description = "System administrator";
|
|
|
|
|
home = "/root";
|
2014-08-20 21:17:48 +02:00
|
|
|
|
shell = mkDefault cfg.defaultUserShell;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
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;
|
2011-11-29 07:08:55 +01:00
|
|
|
|
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";
|
2011-11-29 07:08:55 +01:00
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2015-09-02 17:32:38 +02:00
|
|
|
|
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;
|
2015-03-03 20:23:32 +01:00
|
|
|
|
input.gid = ids.gids.input;
|
2018-08-15 22:10:31 +02:00
|
|
|
|
kvm.gid = ids.gids.kvm;
|
|
|
|
|
render.gid = ids.gids.render;
|
2020-09-24 22:28:52 +02:00
|
|
|
|
shadow.gid = ids.gids.shadow;
|
2012-04-20 14:55:09 +02:00
|
|
|
|
};
|
|
|
|
|
|
2017-07-21 16:41:19 +02:00
|
|
|
|
system.activationScripts.users = stringAfter [ "stdio" ]
|
2014-08-15 01:33:20 +02:00
|
|
|
|
''
|
2018-02-27 20:28:49 +01:00
|
|
|
|
install -m 0700 -d /root
|
|
|
|
|
install -m 0755 -d /home
|
|
|
|
|
|
2014-08-15 01:33:20 +02:00
|
|
|
|
${pkgs.perl}/bin/perl -w \
|
2018-12-15 04:50:31 +01:00
|
|
|
|
-I${pkgs.perlPackages.FileSlurp}/${pkgs.perl.libPrefix} \
|
|
|
|
|
-I${pkgs.perlPackages.JSON}/${pkgs.perl.libPrefix} \
|
2014-08-15 01:33:20 +02:00
|
|
|
|
${./update-users-groups.pl} ${spec}
|
2010-09-13 17:41:38 +02:00
|
|
|
|
'';
|
2009-01-02 17:07:01 +01:00
|
|
|
|
|
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" ] "";
|
2007-06-08 17:41:12 +02:00
|
|
|
|
|
2018-03-20 23:40:57 +01:00
|
|
|
|
# Install all the user shells
|
|
|
|
|
environment.systemPackages = systemShells;
|
|
|
|
|
|
2020-04-28 23:30:34 +02:00
|
|
|
|
environment.etc = (mapAttrs' (name: { packages, ... }: {
|
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));
|
|
|
|
|
|
2019-08-10 10:28:12 +02:00
|
|
|
|
environment.profiles = [
|
|
|
|
|
"$HOME/.nix-profile"
|
|
|
|
|
"/etc/profiles/per-user/$USER"
|
|
|
|
|
];
|
2014-06-26 02:11:28 +02:00
|
|
|
|
|
2014-04-06 12:39:51 +02:00
|
|
|
|
assertions = [
|
|
|
|
|
{ assertion = !cfg.enforceIdUniqueness || (uidsAreUnique && gidsAreUnique);
|
2014-08-15 01:33:20 +02:00
|
|
|
|
message = "UIDs and GIDs must be unique!";
|
2014-04-06 12:39:51 +02:00
|
|
|
|
}
|
2015-09-02 16:09:05 +02:00
|
|
|
|
{ # 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.
|
|
|
|
|
assertion = !cfg.mutableUsers ->
|
2020-07-19 02:24:00 +02:00
|
|
|
|
any id ((mapAttrsToList (name: cfg:
|
2015-09-02 16:09:05 +02:00
|
|
|
|
(name == "root"
|
|
|
|
|
|| cfg.group == "wheel"
|
|
|
|
|
|| elem "wheel" cfg.extraGroups)
|
|
|
|
|
&&
|
2020-06-25 02:02:29 +02:00
|
|
|
|
(allowsLogin cfg.hashedPassword
|
2015-09-02 16:09:05 +02:00
|
|
|
|
|| cfg.password != null
|
|
|
|
|
|| cfg.passwordFile != null
|
|
|
|
|
|| cfg.openssh.authorizedKeys.keys != []
|
|
|
|
|
|| cfg.openssh.authorizedKeys.keyFiles != [])
|
2020-07-19 02:24:00 +02:00
|
|
|
|
) cfg.users) ++ [
|
|
|
|
|
config.security.googleOsLogin.enable
|
|
|
|
|
]);
|
2015-09-02 16:09:05 +02:00
|
|
|
|
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.'';
|
|
|
|
|
}
|
2020-06-25 02:00:56 +02:00
|
|
|
|
] ++ flip mapAttrsToList cfg.users (name: user:
|
|
|
|
|
{
|
|
|
|
|
assertion = (user.hashedPassword != null)
|
|
|
|
|
-> (builtins.match ".*:.*" user.hashedPassword == null);
|
|
|
|
|
message = ''
|
|
|
|
|
The password hash of 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."${name}".hashedPassword`.'';
|
|
|
|
|
}
|
|
|
|
|
);
|
2014-02-07 15:57:28 +01:00
|
|
|
|
|
2020-03-23 02:13:02 +01:00
|
|
|
|
warnings =
|
|
|
|
|
builtins.filter (x: x != null) (
|
|
|
|
|
flip mapAttrsToList cfg.users (name: user:
|
|
|
|
|
# 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 = "[a-z0-9-]+";
|
|
|
|
|
value = "[a-zA-Z0-9/+.-]+";
|
|
|
|
|
options = "${id}(=${value})?(,${id}=${value})*";
|
|
|
|
|
scheme = "${id}(${sep}${options})?";
|
|
|
|
|
content = "${base64}${sep}${base64}";
|
|
|
|
|
mcf = "^${sep}${scheme}${sep}${content}$";
|
|
|
|
|
in
|
2020-06-25 02:02:29 +02:00
|
|
|
|
if (allowsLogin user.hashedPassword
|
2020-06-21 17:01:34 +02:00
|
|
|
|
&& user.hashedPassword != "" # login without password
|
2020-03-23 02:13:02 +01:00
|
|
|
|
&& builtins.match mcf user.hashedPassword == null)
|
2020-06-25 02:02:29 +02:00
|
|
|
|
then ''
|
2020-03-23 02:13:02 +01:00
|
|
|
|
The password hash of user "${name}" may be invalid. You must set a
|
2020-06-23 15:59:14 +02:00
|
|
|
|
valid hash or the user will be locked out of their account. Please
|
2020-06-25 02:02:29 +02:00
|
|
|
|
check the value of option `users.users."${name}".hashedPassword`.''
|
2020-03-23 02:13:02 +01:00
|
|
|
|
else null
|
|
|
|
|
));
|
|
|
|
|
|
2009-01-02 17:07:01 +01:00
|
|
|
|
};
|
2009-09-02 19:35:24 +02:00
|
|
|
|
|
2007-11-09 19:49:45 +01:00
|
|
|
|
}
|