Deleting a user with userdel rebuilds the .db files by invoking pwd_mkdb with the -u option, to update (delete) just that user's entry in the DB. That might be simply flipping a flag in the user entry or something like that, which isn't the same as before the user was originally added. If adding the user originally pushed the DB to use another page, rebalance a btree or expand the hash then deleting the user will generally not undo all those operations.
You can verify this yourself: make a copy of the .db files, add a user and then delete it, and then compare with the original .db files. Philip Guenther On Wed, Feb 12, 2025 at 9:03 PM Samuel B <puser0...@gmail.com> wrote: > > Just to be clear, I'd like to rule out the likelyhood that an unknown > security hole > > was exploited, since I have no idea how to remedy/mitigate that > > > Thanks anyway for your help > > > On Wed, Feb 12, 2025, 6:35 PM Samuel B <puser0...@gmail.com> wrote: >> >> ah, that makes more sense! somehow I missed that. >> >> >> On Wed, Feb 12, 2025, 6:13 PM Todd C. Miller <todd.mil...@sudo.ws> wrote: >>> >>> On Wed, 12 Feb 2025 18:02:12 -0800, Samuel B wrote: >>> >>> > there's not much on pwd.db in the manpages. I ran pwd_mkdb -c on both >>> > *.db files, and for each one I got: >>> > pwd_mkdb: corrupted entry >>> > pwd_mkdb: at line #1 >>> > pwd_mkdb: ...: Inappropriate file type or header >>> > Yet, I added and removed a user (same way as before), then got the >>> > checksums >>> > with sha256. The checksums didn't change, so whatever the "corruption" >>> > is, >>> > it's consistent. >>> >>> That is because "pwd_mkdb -c" is meant to check /etc/master.passwd, >>> not the .db files. >>> >>> - todd
