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

[pelzflorian (Florian Pelz)]

On Mon, Jun 03, 2019 at 03:22:51PM +0200, Ludovic Courtès wrote:
> > After multiple reconfigures, it happened again, my /etc/shadow has !
> > again in the password field.  My recently changed root password became
> > empty as well, like 35902.  I did not even run sudo concurrently.  The
> > password just got locked.
> 
> What were the differences between your config files when you
> reconfigured?
>

For the last reconfigure, there were no differences, although I had
rebooted into an unbootable, older generation with a different
syslog.conf and broken Udevd arguments before booting the new
generation.  I suppose the other victims of this bug have not booted
to unbootable generations?


> Did the config files describe the exact same set of user accounts?
>

Yes, they’re the same.

> Did the user accounts in the config files differ in any way?
>

No, they do not differ.

> Were the user accounts altered in any way in between reconfigures
> (‘passwd’, ‘usermod’, GNOME, etc.)?
> 
>
> Looking at ‘user+group-databases’ in (gnu build accounts), which takes a
> list of <user-account> and a list of <user-group> to produce
> /etc/{passwd,shadow,group}, the only way this could happen is if
> /etc/shadow does not exist at the time of reconfigure.
>
> In that case, ‘user+group-databases’ assumes we’re starting anew, so it
> creates /etc/shadow with the initial passwords specified in the OS
> config.  At that point, the other passwords are lost forever.
> 
> Does Shadow or gnome-control-center or something remove /etc/shadow
> altogether while it’s accessing it?
>

I did not use gnome-control-center or shadow or sudo during the last
reconfigure, except sudo for starting the reconfigure.

> At the very least, adding locking like you suggested should avoid this
> class of problems; I’ll look into that.
> 

I do not know if something somehow accessed /etc/shadow in the
background without my knowledge.  I believe locks are important anyway
to have more guarantees passwords are not lost when Guix is run on a
sensitive multi-user setup.  Thank you for looking into it.

If locks do not stop these issues, it would be nice to have more
detailed logs of shadow changes written to syslog on reconfigure
and/or on reboot.

Regards,
Florian