bug#35996: User account password got locked when booting old generation

[pelzflorian (Florian Pelz)]

On Sat, Jun 01, 2019 at 11:37:51PM +0200, Ludovic Courtès wrote:
> This is definitely not a problem when booting.  It could be a problem if
> you’re concurrently running ‘guix system reconfigure’ (which runs
> activation snippets, including the account updating code) and some other
> program, such as ‘passwd’, that assumes it holds an exclusive lock on
> the file.  Though in that case, the worst that could happen is that the
> changes made by Guix would be undoed by that other program.

Thank you for explaining!

OK.  Also why would a read error cause the password to get locked
anyway.  I suppose this is an issue with mingetty or something locking
the password, perhaps after too many failed login attempts.  (Note
that I’m prone to making typos because with this Macbook keyboard key
presses are sometimes recognized twice on and only on a virtual
console.)  I will investigate mingetty next.


I also tried running this script:

#!/run/current-system/profile/bin/bash
MD5=$(sudo md5sum /etc/shadow)
echo "Current /etc/shadow has md5sum: $MD5"
until [ "$(sudo md5sum /etc/shadow)" != "$MD5" ]; do
    sudo guix system roll-back
    sudo guix system reconfigure /etc/config.scm
done
notify-send "/etc/shadow changed!" "Maybe I reproduced the issue."

After repeatedly reconfiguring for some 40 minutes I still got the
same /etc/shadow.

(But I think it broke my motherboard, because recently the output of
reconfigure changed from

[…]
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?).
shepherd: Service user-homes has been started.
shepherd: Service term-auto could not be started.
bootloader successfully installed on '/boot/efi'

to

[…]
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?).
shepherd: Service user-homes has been started.
shepherd: Service term-auto could not be started.
error: 
'/gnu/store/h5bi85lgnpqcjx2avy126lwiss01idsj-grub-efi-2.02/sbin/grub-install 
--boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' exited 
with status 1; output follows:

  Installing for x86_64-efi platform.
  Could not prepare Boot variable: No such file or directory
  /gnu/store/h5bi85lgnpqcjx2avy126lwiss01idsj-grub-efi-2.02/sbin/grub-install: 
error: efibootmgr failed to register the boot entry: Input/output error.

guix system: error: failed to install bootloader 
/gnu/store/y6p93xjdbpbp0z2kc0gw5yqjppmdsq7g-bootloader-installer


I now get this on every reconfigure.  I tried rebooting; this was a
bad idea; I csnnot boot anymore.  But that is unrelated.  Maybe I will
install GRUB as if it were an external hard drive from now on.)


> 
> > The elogind source code in src/basic/user-util.c contains code for
> > locking /etc/shadow, with a comment that explains why its lckpwdf is
> > implemented differently from shadow-utils.
> >
> > AccountsService appears to only be usable for reading /etc/shadow, not
> > for writing it, contrary to what the Guix manual claims (??). 
> 
> That might be a bug.
> 
> > For writing passwords, gnome-control-center does not use
> > AccountsService, it calls /usr/bin/passwd directly in its source code
> > in panels/user-accounts/run-passwd.c.
> 
> That’s definitely a bug to fix: it should invoke
> /run/setuid-programs/passwd instead.
> 
> Thanks for investigating,
> Ludo’.

I will try and make patches once I can reboot into Guix again.

Regards,
Florian