#471691 base-passwd: update-passwd leaves account files in inconsistent state according to pwck (should remove user with low UID from shadow, too)

Package:
base-passwd
Source:
base-passwd
Description:
Debian base system master password and group files
Submitter:
Frans Pop
Date:
2017-09-15 18:27:09 UTC
Severity:
normal
#471691#5
Date:
2008-03-19 13:04:09 UTC
From:
To:
When during a new installation using Debian Installer the base system
installation step (which uses debootstrap) fails and is retried, the
second installation fails with the following error:

debootstrap: Setting up login (1:4.1.0-2) ...
debootstrap: Setting up passwd (1:4.1.0-2) ...
debootstrap: no matching password file entry in /etc/passwd
debootstrap: delete line 'libuuid:!:13957:0:99999:7:::'?
debootstrap: pwck: no changes
debootstrap: Please correct the error and rerun `/sbin/shadowconfig on'
debootstrap: dpkg: error processing passwd (--configure):
debootstrap:  subprocess post-installation script returned error exit status 1

Although running debootstrap on a non-clean target is not preferred,
this does seem like an idempotency issue that should be resolved.

Note that the failure of the initial base installation step is
completely unrelated to passwd: the initial installation of passwd (and
the rest of debootstrap) was without problems.

#471691#10
Date:
2008-03-19 13:38:03 UTC
From:
To:
That seems to be passwd.postinst calling "shadowconfig on" calling
pwck -q, which fails.  Presumably the failure is due to a real
inconsistency with system account datafiles.

I note that pwck -q doesn't seem to have the intended effect
(-q shouldn't prompt).

Can you show the relevant content of the debootstrap regarding uuid
packages?  Also the output of: grep uuid
/etc/{passwd,shadow,group,gshadow} .

#471691#15
Date:
2008-03-19 14:18:57 UTC
From:
To:
Even if it does prompt, I don't think it actually asks for input as that
would likely have resulted in a hang. I'm not completely sure of that
though.

Attached the full log of the failed debootstrap run.

Note that I've filed a separate BR against dpkg for the excessive retrying
to configure passwd.
/etc/passwd:libuuid:x:42:101::/var/lib/libuuid:/bin/sh
/etc/shadow:libuuid:!:13957:0:99999:7:::
/etc/group:libuuid:x:101:
/etc/gshadow:libuuid:!::

After the second failed run the line in /etc/passwd has disappeared:
/etc/shadow:libuuid:!:13957:0:99999:7:::
/etc/group:libuuid:x:101:
/etc/gshadow:libuuid:!::

Cheers,
FJP

#471691#20
Date:
2008-03-19 14:57:59 UTC
From:
To:
clone 471667 -1
reassign -1 base-passwd
retitle -1 base-passwd: update-passwd leaves account files in inconsistent state according to pwck (should remove user with low UID from shadow, too)
found -1 3.5.17
thanks
I assumed it was just trying to read from a closed FD (perhaps not due
to dpkg not providing one in general, but IDK what your installation
environment is, and guessed that it didn't provide a stdin).

Do you know what version libuuid was initially installed?  I suspect
one of the problems was fixed in libuuid1 1.40.7-1 (See #466929).  If
you agree, the initial report (#471667) can be closed.

I changed my mind about the passwd pwck -q prompting problem.  On
rereading the manual page, the description isn't that it avoids
prompting, but rather inhibits report of warnings (errors still cause
prompts).

That leaves one remaining problem (plus excessive configuration
attempts by dpkg): base-passwd leaves the account files in a state
where pwck later fails.  base-passwd should also have removed the
relevant line from /etc/shadow.

#471691#33
Date:
2011-02-09 11:45:54 UTC
From:
To:
The same problem exists for /etc/gshadow .
base-passwd offers to remove a group with gid<100 from /etc/group but fails
to update /etc/gshadow as well.