Control: reassign -1 adduser 3.154
Control: affects -1 + dbus-system-bus-common
For the adduser maintainers, the minimal steps to reproduce this issue
in an expendable chroot/container/thing are:
# apt update && apt upgrade
# apt install adduser
# adduser --system _star
# adduser --system _bang
# adduser --system _bangstar
# echo '_star:*' | chpasswd -e
# echo '_bang:!' | chpasswd -e
# echo '_bangstar:!*' | chpasswd -e
# adduser --system _bang
# adduser --system _star
# adduser --system _bangstar
Expected result: all commands succeed, as they did (I think) in trixie.
Actual result: on sid, the last `adduser --system _bangstar` (after
setting the password) fails with the same error message shown in the
subject line.
Alternative steps to get to the same error, which I think are a closer
match for what actually happened on Santiago's systems, are to do this
in a chroot/container/thing that does not already have a _bangstar user:
# apt update && apt upgrade
# apt install adduser systemd-standalone-sysusers
# systemd-sysusers - <<EOF
u _bangstar
EOF
# adduser --system _bangstar
although in some versions of systemd you might have to use
u! _bangstar
as input to get the same result.
On Thu, 29 Jan 2026 at 16:33:11 +0100, Santiago Vila wrote:
- It is correct or incorrect for trixie images to have "!*" in the
messagebus user?
I am not an expert on the finer points of shadow(5), but I think "!*" is
at least as correct as "!", and possibly more so.
According to shadow(5), an encrypted-password field starting with "!"
indicates a user whose account is locked, and everything after the "!"
is what their encrypted password was before the account was locked.
Meanwhile "*" is not a valid result of crypt(3), meaning that "*"
indicates a user who cannot authenticate using a password (but they
might be able to authenticate with non-password mechanisms like ssh
public keys).
Combining the two, "!*" ought to mean that messagebus's account is
locked, *and* even if it wasn't locked, messagebus would still not be
able to authenticate using a password. This seems like what we want for
the system uids that exist to run daemons, like messagebus.
Meanwhile "!" indicates a user whose account is locked, but if it was
somehow unlocked for whatever reason, they would be able to log in (for
example via getty/login) by using a blank password, or perhaps without a
password prompt at all. I think we never actually want that behaviour
for system users like messagebus.
In newer versions of systemd and sysusers.d(5), a line starting with "u
messagebus" would create a user with encrypted password "*", but a line
starting with "u! messagebus" would create a user with encrypted
password "!*". With my dbus upstream hat on, I've had a merge request
to change its sysusers.d snippet to use "u!", which seems like a
positive change: you shouldn't be able to log in as messagebus, under
any circumstances.
However, it seems that this behaviour has evolved over time: in some
versions of systemd, including trixie and sid, plain "u" creates a
locked account with encrypted password "!*".
- It is correct or incorrect for adduser/useradd to say that the user
has a password when it has "!*"?
My reading of shadow(5) is that it's incorrect, because neither "!*" nor
"*" is a possible output of crypt(3), therefore neither can be said to
be a password. But I could be wrong, I'm not an expert.
On Thu, 29 Jan 2026 at 16:01:17 +0100, Santiago Vila wrote:
[Is it] a bug in trixie that [messagebus] user has a UID like 996?
No, these are dynamically-allocated uids in the 100-999 range and any
uid in that range is as good as any other.
Typically uids close to the low end (like my 108) indicate that the
account was created with adduser, and the high end (like your 990 or
996) indicates that the account was created with systemd-sysusers.
[Is it] a bug in schroot at all that it copies some files via the
nssdatabases mechanism?
Yes and no. It's schroot working as designed, but for the use-case where
you are using sbuild to get a clean, predictable, reproducible
environment for doing builds, it could be argued that it's a bug in
sbuild and it shouldn't be letting this implementation detail of the
host leak into the chroot/container. The unshare backend is the
solution for this maybe-bug.
smcv
