chsh corrupts /etc/pwd.db

[Miroslav Lachman]

Alan Somers wrote on 2019/08/22 04:07:
> On Wed, Aug 21, 2019 at 7:22 PM Tom Samplonius <tom at samplonius.org> wrote:
>>
>>
>>
>> On Aug 21, 2019, at 2:55 PM, Alan Somers <asomers at freebsd.org> 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