[Pkg-shadow-devel] Bug#1126595: dbus-system-bus-common: fatal: The user `messagebus' already exists and has a password

[Simon McVittie]

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