To be compatible with eb2f44c18c (Generate
/etc/passwd and /etc/group at build time). Without this you'll get this:
$ nixos-rebuild build
[...]
user-thrown exception: The option `users.extraGroups.unnamed-9.1.gid' is used but not defined.
Currently very basic gnome-shell launches on my laptop. Quite some
services won't start yet, most notable is gnome-control-center.
GTK3 apps still don't have theming applied and for example launching
chromium results in horrible red windows.
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).
switch-to-configuration.pl is currently hard-coded to assume that if a
unit is in the "auto-restart" state that something has gone wrong, but
this is not strictly true. For example, I run offlineimap as a oneshot
service restarting itself every minute (on success). NixOS currently
thinks that offlineimap has failed to start as it enters the
auto-restart state, because it doesn't consider why the unit failed.
This commit changes switch-to-configuration.pl to inspect the full
status of a unit in auto-restart state, and now only considers it failed
if the ExecMainStatus is non-zero.
[Bjørn Forsman <bjorn.forsman@gmail.com>:
- use types.lines instead of types.string. The former joins strings
with "\n" and the latter with "" (and is deprecated).
]
This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these
lines has the same format as would be the case for the userless authentication, except that they are prepended with a
SHA-512 of the user's id.
IIUC, <nixos> is going to be deprecated someday in the future, and as
most of those references are already replaced I guess it's safe to
replace it here as well, as it is only relevant on new/updated
installations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'.
Used binaries:
* uuidgen - for generation of random sequence numbers
* ykchalresp - for challenging a Yubikey
* ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise)
* openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption
Main differences to the specification mentioned above:
* No user management (yet), only one password+yubikey per LUKS device
* SHA-512 instead of CRC-16 for checksum
Main differences to the previous implementation:
* Instead of changing the key slot of the LUKS device each boot,
the actual key for the LUKS device will be encrypted itself
* Since the response for the new challenge is now calculated
locally with openssl, the MITM-USB-attack with which previously
an attacker could obtain the new response (that was used as the new
encryption key for the LUKS device) by listening to the
Yubikey has ideally become useless (as long as uuidgen can
successfuly generate new random sequence numbers).
Remarks:
* This is not downwards compatible to the previous implementation
This will allow overriding package-provided units, or overriding only a
specific instance of a unit template.
Signed-off-by: Shea Levy <shea@shealevy.com>
