From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pelzflorian (Florian Pelz)" Subject: bug#35996: User account password got locked when booting old generation Date: Sun, 2 Jun 2019 09:05:45 +0200 Message-ID: <20190602070545.xp2pqlnzsthpjtbw@pelzflorian.localdomain> References: <20190529204517.mqn5xrw23xib4i3u@pelzflorian.localdomain> <877ea6l1on.fsf@gnu.org> <20190601055238.jkhefpupavz7aipi@pelzflorian.localdomain> <20190601145834.f4wgm4oqmdyej7n5@pelzflorian.localdomain> <87r28dc7gw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:37415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXKZ9-000226-S0 for bug-guix@gnu.org; Sun, 02 Jun 2019 03:06:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hXKZ8-00076X-NU for bug-guix@gnu.org; Sun, 02 Jun 2019 03:06:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53985) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hXKZ8-00076P-Jb for bug-guix@gnu.org; Sun, 02 Jun 2019 03:06:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hXKZ8-0004UA-Bc for bug-guix@gnu.org; Sun, 02 Jun 2019 03:06:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87r28dc7gw.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 35996@debbugs.gnu.org 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