Note that this issue is about Guix System; users of Guix on other
distros are unaffected.
Maxime Devos <maximede...@telenet.be> skribis:
> The attack consists of the user being logged in after the account
> skeletons have been copied to the home directory, but before the
> owner of the account skeletons have been set. The user then deletes
> a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces
> it with a symbolic link to a file not owned by the user, such as
> @file{/etc/shadow}.
>
> The activation code then changes the ownership
> of the file the symbolic link points to instead of the symbolic
> link itself. At that point, the user has read-write access
> to the target file.
To give a bit more context, account creation on Guix System happens
while ‘guix system reconfigure’ is running.
The user whose account is being created thus needs to be able to log in
right during the time window described above.
Users whose password is uninitialized (i.e., the ‘password’ field of
<user-account> is left unspecified¹) cannot log in at that point, unless
possibly if the OpenSSH configuration specifies an authorized key for
the user account.
Ludo’.
¹ https://guix.gnu.org/manual/en/html_node/User-Accounts.html
²
https://guix.gnu.org/manual/en/html_node/Networking-Services.html#index-openssh_002dservice_002dtype
