On Fri, 28 Feb 2025 at 07:20:59 +0100, Marc Haber wrote:
dbus-system-bus-common's postinst makes relly sure that adduser behaves
policy compliant
...
That is kind of redundant since system users already get a disabled
password, home /nonexistent and /nonexistent never gets created. So, I
think that adduser --system --group "$MESSAGEUSER" will already do what
is policy compliant.
It's been that verbose for around 20 years (probably with a certain
amount of cargo-cult from other packages that created system users),
so I hope you'll understand if I don't treat this as urgent.
Can I rely on the behaviour you describe in the adduser versions in all
suites >= bookworm (preferably bullseye), or would this need a versioned
dependency?
If I'm reading the changelog correctly, it looks as though
--no-create-home would certainly have been necessary in order to avoid
creating /nonexistent (clearly not what we want!) before 3.130, which
is in bookworm but not bullseye? Or would a higher dependency than that
be wise?
Please consider simplifying your adduser call, or maybe migrate to
systemd-sysusers which might actually fit the systemd/dbus universe
better.
While I am personally very much in favour of creating system users
declaratively, dbus is considerably older than systemd and specifically
does not require it, and I don't think I have enough spoons to deal with
the accusations of malice and betrayal that I'd expect to receive from
sysv-rc users if they perceive it as gaining a systemd dependency. What I
might do is to make it depend on adduser | systemd-sysusers, preferring
to use systemd-sysusers at runtime but falling back to adduser if that
isn't available, which seems to have worked OK for polkitd.
(With my upstream hat on, dbus already provides a sysusers.d(5) fragment,
which is already relied on by distros that are more opinionated about
their low-level components.)
smcv
