Hi,

this can be easily seen with:

$ piuparts --apt --distribution=unstable \
  '--bootstrapcmd=mmdebstrap --skip=check/empty --variant=apt' \
  passwd
[..]
0m19.9s ERROR: FAIL: Package purging left files on system:
  /etc/.pwd.lock         not owned

Note that piuparts.d.o has passwd installed in it's base chroot so it
currently does not detect this. Maybe piuparts maintainers (Cced) want
to fix this, there are probably more cases like this.

The problem is that passwd.postinst is calling `shadowconfig on` but
nothing is turning it off again. Not sure if turning it off in prerm or
just enable shadow by default is the better solution here.

Cheers Jochen

Thanks!

I think turning shadow passwords -off- when uninstalling passwd is a
no-go.

Well, but where. base-passwd? Also not so useful if there is no
chance of having *passwords* at all (because there are no tools
to write a password without `passwd`).

Maybe `shadowconfig on` should just delete the lock file? Didn't
investigate yet if this is feasible.

Chris

* Chris Hofstaedtler <zeha@debian.org> [2025-12-28 10:00]:

Agreed.

I think that would make sense. base-passwd would need to:

sed -i 's/\*/+/' passwd.master group.master

And also ship a shadow.master and gshadow.master or generate it with
something like:

sed 's/\([^:]*\):.*/\1:*::/' passwd.master > shadow.master
sed 's/\([^:]*\):.*/\1:*::/' group.master > gshadow.master

I would assume that represents most of the Debian systems anyhow so it
makes sense to ship it by default.

Not sure I understand, can you explain?

Probably also a good idea but that would be libc as shadowconfig is
using pwconv which is calling lckpwdf() and that is creating the lock
file. Maybe it should clean it up upon ulckpwdf().

Feel free to clone and reassign if you agree.

Cheers Jochen

actual passwords to "shadow" (protect), and thus you don't need
shadow passwords at all.

But if for base-passwd it is easy to make sure all systems start out
as shadow-enabled, that would also seem good. At least it would
reduce the number of states a Debian system can be in.

@Colin: what do you think about this? Would you be willing to
include this in base-passwd?
(For context: currently installing passwd turns on shadow passwords,
and that leaves the password database lockfile around.)

I think that might not be race-free to do in general?

For the shadowconfig case, I'd feel okay to rm the file afterwards,
under the assumption it will happen only once very early in the life
of a Debian system, as part of a dpkg install scenario.

Lets discuss here a bit more.

Chris

* Chris Hofstaedtler <zeha@debian.org> [251228 13:27]:
[..]

Another option might be to ship /etc/.pwd.lock as a proper conffile
in a package. Even if src:shadow would clean up after installing,
other packages using lckpwdf will still cause this issue.

Given lckpwdf is in src:glibc, maybe there?

Chris

Hi,

This could be libc-bin, which is still marked as Essential at this
stage. That said, are we sure that dpkg will never touch this file on
upgrade? Otherwise that just defeat the purpose of a lock file.

Regards
Aurelien

I'm not exactly sure of the best implementation, but I'm generally in
favour of having base-passwd turn on shadow passwords if that's also
what you'd prefer.

There should be no need for shadow.master etc. though.  update-passwd
already handles updating /etc/shadow, and if it needs to be changed to
update /etc/gshadow as well in a similar way then that's something we
could do.

* Colin Watson <cjwatson@debian.org> [251229 21:14]:

Yes, then lets please do it.

Let me know if you need any changes in src:shadow.

At least after base-passwd starts enabling shadow passwords, the
`passwd` package should stop calling `shadowconfig on`. I shall
remove that once base-passwd is ready.

Many thanks!

Chris