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

484 lines
15 KiB
Nix
Raw Normal View History

{ config, lib, 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;
passwordDescription = ''
The options <literal>hashedPassword</literal>,
<literal>password</literal> and <literal>passwordFile</literal>
controls what password is set for the user.
<literal>hashedPassword</literal> overrides both
<literal>password</literal> and <literal>passwordFile</literal>.
<literal>password</literal> overrides <literal>passwordFile</literal>.
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 <literal>users.mutableUsers</literal> 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
<literal>users.mutableUsers</literal> is false, you cannot change
user passwords, they will always be set according to the password
options.
'';
userOpts = { name, config, ... }: {
options = {
name = mkOption {
type = types.str;
description = ''
The name of the user account. If undefined, the name of the
attribute set will be used.
'';
};
description = mkOption {
type = 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 <filename>/etc/passwd</filename>.
'';
};
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</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).
'';
};
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>.
'';
};
group = mkOption {
type = types.str;
default = "nogroup";
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.str;
default = "/var/empty";
description = "The user's home directory.";
};
shell = mkOption {
type = types.str;
default = "/run/current-system/sw/sbin/nologin";
description = "The path to the user's shell.";
};
subUidRanges = mkOption {
type = types.listOf types.optionSet;
default = [];
example = [
{ startUid = 1000; count = 1; }
{ startUid = 100001; count = 65534; }
];
options = [ subordinateUidRange ];
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 {
type = types.listOf types.optionSet;
default = [];
example = [
{ startGid = 100; count = 1; }
{ startGid = 1001; count = 999; }
];
options = [ subordinateGidRange ];
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.
'';
};
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 = ''
If true, the home directory will be created automatically. If this
option is true and the home directory already exists but is not
owned by the user, directory owner and group will be changed to
match the user.
'';
};
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
<literal>cfg.defaultUserShell</literal>.
'';
};
hashedPassword = mkOption {
type = with types; uniq (nullOr str);
default = null;
description = ''
Specifies the (hashed) password for the user.
${passwordDescription}
'';
};
password = mkOption {
2013-10-30 17:37:45 +01:00
type = with types; uniq (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}
'';
};
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 {
type = with types; uniq (nullOr string);
default = null;
description = ''
The path to a file that contains 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 <literal>chpasswd -e</literal> 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
'';
};
};
config = mkMerge
[ { name = mkDefault name;
shell = mkIf config.useDefaultShell (mkDefault cfg.defaultUserShell);
}
(mkIf config.isNormalUser {
group = mkDefault "users";
createHome = mkDefault true;
home = mkDefault "/home/${name}";
useDefaultShell = mkDefault true;
isSystemUser = mkDefault false;
})
];
};
groupOpts = { name, config, ... }: {
options = {
name = mkOption {
type = 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 string;
default = [];
description = ''
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
'';
};
};
config = {
name = mkDefault name;
};
};
subordinateUidRange = {
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 = {
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'';
};
};
mkSubuidEntry = user: concatStrings (
map (range: "${user.name}:${toString range.startUid}:${toString range.count}\n")
user.subUidRanges);
subuidFile = concatStrings (map mkSubuidEntry (attrValues cfg.extraUsers));
mkSubgidEntry = user: concatStrings (
map (range: "${user.name}:${toString range.startGid}:${toString range.count}\n")
user.subGidRanges);
subgidFile = concatStrings (map mkSubgidEntry (attrValues cfg.extraUsers));
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;
uidsAreUnique = idsAreUnique (filterAttrs (n: u: u.uid != null) cfg.extraUsers) "uid";
gidsAreUnique = idsAreUnique (filterAttrs (n: g: g.gid != null) cfg.extraGroups) "gid";
spec = pkgs.writeText "users-groups.json" (builtins.toJSON {
inherit (cfg) mutableUsers;
users = mapAttrsToList (n: u:
{ inherit (u)
name uid group description home shell createHome isSystemUser
password passwordFile hashedPassword;
}) cfg.extraUsers;
groups = mapAttrsToList (n: g:
{ inherit (g) name gid;
2014-09-22 19:18:08 +02:00
members = g.members ++ (mapAttrsToList (n: u: u.name) (
filterAttrs (n: u: elem g.name u.extraGroups) cfg.extraUsers
2014-09-22 19:18:08 +02:00
));
}) cfg.extraGroups;
});
in {
###### 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 true, you are free to add new users and groups to the system
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
contents generated from the <literal>users.extraUsers</literal> and
<literal>users.extraGroups</literal> options. If
<literal>mutableUsers</literal> is false, the contents of the user and
group files will simply be replaced on system activation. This also
holds for the user passwords; if this option is false, all changed
passwords will be reset according to the
<literal>users.extraUsers</literal> configuration on activation. If
this option is true, the initial password for a user will be set
according to <literal>users.extraUsers</literal>, but existing passwords
will not be changed.
'';
};
users.enforceIdUniqueness = mkOption {
type = types.bool;
default = true;
description = ''
Whether to require that no two users/groups share the same uid/gid.
'';
};
users.extraUsers = mkOption {
default = {};
type = types.loaOf types.optionSet;
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.
'';
options = [ userOpts ];
};
users.extraGroups = mkOption {
default = {};
example =
{ students.gid = 1001;
hackers = { };
};
type = types.loaOf types.optionSet;
description = ''
Additional groups to be created automatically by the system.
'';
options = [ groupOpts ];
};
security.initialRootPassword = mkOption {
type = types.str;
default = "!";
example = "";
description = ''
The (hashed) password for the root account set on initial
installation. The empty string denotes that root can login
locally without a password (but not via remote services such
as SSH, or indirectly via <command>su</command> or
<command>sudo</command>). The string <literal>!</literal>
prevents root from logging in using a password.
Note that setting this option sets
<literal>users.extraUsers.root.hashedPassword</literal>.
Also, if <literal>users.mutableUsers</literal> is false
you cannot change the root password manually, so in that case
the name of this option is a bit misleading, since it will define
the root password beyond the user initialisation phase.
'';
};
};
###### implementation
config = {
users.extraUsers = {
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";
nixos: add grsecurity module (#1875) This module implements a significant refactoring in grsecurity configuration for NixOS, making it far more usable by default and much easier to configure. - New security.grsecurity NixOS attributes. - All grsec kernels supported - Allows default 'auto' grsec configuration, or custom config - Supports custom kernel options through kernelExtraConfig - Defaults to high-security - user must choose kernel, server/desktop mode, and any virtualisation software. That's all. - kptr_restrict is fixed under grsecurity (it's unwriteable) - grsecurity patch creation is now significantly abstracted - only need revision, version, and SHA1 - kernel version requirements are asserted for sanity - built kernels can have the uname specify the exact grsec version for development or bug reports. Off by default (requires `security.grsecurity.config.verboseVersion = true;`) - grsecurity sysctl support - By default, disabled. - For people who enable it, NixOS deploys a 'grsec-lock' systemd service which runs at startup. You are expected to configure sysctl through NixOS like you regularly would, which will occur before the service is started. As a result, changing sysctl settings requires a reboot. - New default group: 'grsecurity' - Root is a member by default - GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID, making it possible to easily add users to this group for /proc access - AppArmor is now automatically enabled where it wasn't before, despite implying features.apparmor = true The most trivial example of enabling grsecurity in your kernel is by specifying: security.grsecurity.enable = true; security.grsecurity.testing = true; # testing 3.13 kernel security.grsecurity.config.system = "desktop"; # or "server" This specifies absolutely no virtualisation support. In general, you probably at least want KVM host support, which is a little more work. So: security.grsecurity.enable = true; security.grsecurity.stable = true; # enable stable 3.2 kernel security.grsecurity.config = { system = "server"; priority = "security"; virtualisationConfig = "host"; virtualisationSoftware = "kvm"; hardwareVirtualisation = true; } This module has primarily been tested on Hetzner EX40 & VQ7 servers using NixOps. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-04-06 21:18:12 +02:00
extraGroups = [ "grsecurity" ];
hashedPassword = mkDefault config.security.initialRootPassword;
};
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;
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.extraGroups = {
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;
nixos: add grsecurity module (#1875) This module implements a significant refactoring in grsecurity configuration for NixOS, making it far more usable by default and much easier to configure. - New security.grsecurity NixOS attributes. - All grsec kernels supported - Allows default 'auto' grsec configuration, or custom config - Supports custom kernel options through kernelExtraConfig - Defaults to high-security - user must choose kernel, server/desktop mode, and any virtualisation software. That's all. - kptr_restrict is fixed under grsecurity (it's unwriteable) - grsecurity patch creation is now significantly abstracted - only need revision, version, and SHA1 - kernel version requirements are asserted for sanity - built kernels can have the uname specify the exact grsec version for development or bug reports. Off by default (requires `security.grsecurity.config.verboseVersion = true;`) - grsecurity sysctl support - By default, disabled. - For people who enable it, NixOS deploys a 'grsec-lock' systemd service which runs at startup. You are expected to configure sysctl through NixOS like you regularly would, which will occur before the service is started. As a result, changing sysctl settings requires a reboot. - New default group: 'grsecurity' - Root is a member by default - GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID, making it possible to easily add users to this group for /proc access - AppArmor is now automatically enabled where it wasn't before, despite implying features.apparmor = true The most trivial example of enabling grsecurity in your kernel is by specifying: security.grsecurity.enable = true; security.grsecurity.testing = true; # testing 3.13 kernel security.grsecurity.config.system = "desktop"; # or "server" This specifies absolutely no virtualisation support. In general, you probably at least want KVM host support, which is a little more work. So: security.grsecurity.enable = true; security.grsecurity.stable = true; # enable stable 3.2 kernel security.grsecurity.config = { system = "server"; priority = "security"; virtualisationConfig = "host"; virtualisationSoftware = "kvm"; hardwareVirtualisation = true; } This module has primarily been tested on Hetzner EX40 & VQ7 servers using NixOps. Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-04-06 21:18:12 +02:00
grsecurity.gid = ids.gids.grsecurity;
};
system.activationScripts.users = stringAfter [ "etc" ]
''
${pkgs.perl}/bin/perl -w \
-I${pkgs.perlPackages.FileSlurp}/lib/perl5/site_perl \
-I${pkgs.perlPackages.JSON}/lib/perl5/site_perl \
${./update-users-groups.pl} ${spec}
'';
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" ] "";
environment.etc."subuid" = {
text = subuidFile;
mode = "0644";
};
environment.etc."subgid" = {
text = subgidFile;
mode = "0644";
};
assertions = [
{ assertion = !cfg.enforceIdUniqueness || (uidsAreUnique && gidsAreUnique);
message = "UIDs and GIDs must be unique!";
}
];
};
}