unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 35996@debbugs.gnu.org
Subject: bug#35996: User account password got locked when booting old generation
Date: Mon, 3 Jun 2019 16:52:09 +0200	[thread overview]
Message-ID: <20190603145209.ub7663zp7yh7n7i4@pelzflorian.localdomain> (raw)
In-Reply-To: <87tvd6erbo.fsf@gnu.org>

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

  reply	other threads:[~2019-06-03 14:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 20:45 bug#35996: User account password got locked when booting old generation pelzflorian (Florian Pelz)
2019-05-31 22:05 ` Ludovic Courtès
2019-06-01  5:52   ` pelzflorian (Florian Pelz)
2019-06-01 14:58     ` pelzflorian (Florian Pelz)
2019-06-01 21:37       ` Ludovic Courtès
2019-06-02  7:05         ` pelzflorian (Florian Pelz)
2019-06-02  9:38           ` Ludovic Courtès
2019-06-02 10:21             ` pelzflorian (Florian Pelz)
2019-06-02 16:00               ` Ludovic Courtès
2019-06-03  6:03                 ` pelzflorian (Florian Pelz)
2019-06-03  6:14                   ` Gábor Boskovits
2019-06-03  7:18                   ` pelzflorian (Florian Pelz)
2019-06-03 15:22                     ` Ludovic Courtès
2019-06-03 17:07                       ` pelzflorian (Florian Pelz)
2019-06-03 13:22                   ` Ludovic Courtès
2019-06-03 14:52                     ` pelzflorian (Florian Pelz) [this message]
2019-06-04  9:22                       ` Ludovic Courtès
2019-06-04 12:17                         ` pelzflorian (Florian Pelz)
2019-06-04 14:12                           ` pelzflorian (Florian Pelz)
2019-06-04 17:17                             ` pelzflorian (Florian Pelz)
2019-06-04 21:21                               ` Ludovic Courtès
2019-06-05  6:16                                 ` pelzflorian (Florian Pelz)
2019-06-05  9:54                                   ` Ludovic Courtès
2019-06-05 11:06                                     ` pelzflorian (Florian Pelz)
2019-06-05 21:13                                       ` Ludovic Courtès
2019-06-06  7:01                                         ` pelzflorian (Florian Pelz)
2019-06-06  8:04                                           ` Ludovic Courtès
2019-06-03 16:01                     ` Danny Milosavljevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190603145209.ub7663zp7yh7n7i4@pelzflorian.localdomain \
    --to=pelzflorian@pelzflorian.de \
    --cc=35996@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).