From owner-freebsd-stable@freebsd.org Thu Aug 22 09:21:21 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A59A4C327B for ; Thu, 22 Aug 2019 09:21:21 +0000 (UTC) (envelope-from SRS0=Xyx3=WS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46DfD13wTgz4Fp6; Thu, 22 Aug 2019 09:21:21 +0000 (UTC) (envelope-from SRS0=Xyx3=WS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8927128416; Thu, 22 Aug 2019 11:21:18 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 48D4D2840C; Thu, 22 Aug 2019 11:21:17 +0200 (CEST) Subject: Re: chsh corrupts /etc/pwd.db To: Alan Somers , Tom Samplonius Cc: FreeBSD References: <208B5647-9D41-4F0E-9111-32CBFF8491D1@samplonius.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <7f7ff711-342e-fc8a-d2c9-50dd1a90acd8@quip.cz> Date: Thu, 22 Aug 2019 11:21:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46DfD13wTgz4Fp6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.995,0]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 09:21:21 -0000 Alan Somers wrote on 2019/08/22 04:07: > On Wed, Aug 21, 2019 at 7:22 PM Tom Samplonius wrote: >> >> >> >> On Aug 21, 2019, at 2:55 PM, Alan Somers wrote: >> >> Today I tried to use chsh to change my shell from bash to fish. The >> command completed successfully, but new logins continued to use bash! >> Investigating, I discovered that /etc/pwd.db and /etc/spwd.db seem to >> contain 3-4 entries per user. One of those still refers to my old >> >> >> Berkeley DB files can only have a single index, so users are stored three times, once by username, once by uid, and once by line number. So that isn’t corruption. > > But why was my entry stored four times? > >> >> >> shell. Worse, if I try using chsh again, it fails with an "entry >> inconsistent" error, and I have to restore the password files from >> backup. Has anybody seen something like this before? This is just a >> single system, with no NIS or LDAP. >> >> >> You shouldn’t need to restore the files. You should be able to just regenerate the *.db files from the master.passwd file: >> >> /usr/sbin/pwd_mkdb -p /etc/master.passwd > > Ok, that worked. Thanks! > >> >> >> Unless, of course your master.passwd file was damaged. But the *.db files are really just caches for faster access to user data. The real master file is master.passwd. >> >> >> The ch* tools typically just change master.passwd, and then call pwd_mkdb to rebuild the *.db files. > > The pwd.db file from before the snapshot only has three entries. From > after, it has four, and one of them has the wrong shell. So it does > seem that chsh is corrupting the file. And fortunately the problem is > repeatable. Any ideas about how to debug it? > > -Alan > > P.S. I failed to mention earlier that this is happening on 12.0-RELEASE-p10 I run in to something similar from time to time from about 10.x or 8.x (i skipped 9.x) I do not remember exactly what command did the corruption, if it was vipw or chsh or something else to manipulate user database. The fix was easy - run it again or use pwd_mkdb Miroslav Lachman