Re: creating system user IDs for system-wide daemons (was: wesnoth)

On Sun, 31 Dec 2023 at 03:45:40 -0500, P. J. McDermott wrote:
> I wonder how a systemd service file provided by an upstream source
> archive is supposed to handle this then, since as I said I proposed a
> similar change upstream (which thanks to you I now see should probably
> not be merged as-is, though I don't think upstream's current use of
> nobody:users is any better, since systemd will even warn about it).
> I'll have to try to find some examples of what users/groups other
> upstreams use in their provided systemd/init.d/etc. service files.

A systemd service file can rely on systemd-sysusers being present, so it
can use a sysusers.d(5) fragment to create a system user, in conjunction
with a systemd service that runs as that same user.  A good example
is the dbus source package, which has bus/sysusers.d/dbus.conf.in to
create a user, and bus/dbus.service.in which runs `dbus-daemon --system`
as that user. If I was packaging dbus today, I'd use _dbus as the name
of its user, but for historical reasons it's named messagebus in Debian
derivatives (and typically messagebus, dbus or _dbus in other distros).

The starts-with-an-underscore convention is a relatively recent thing
in Debian: I think we copied it from FreeBSD. The intention is to avoid
weird situations where for example dbus can't be installed correctly
on a system where a user named Derek Brian Usborne-Smith has already
created a user account named using his initials.

The user/group name can either be hard-coded as something like _wesnoth
or wesnoth (and patched by any distros that have policies that would prefer
a different name), or be a configure-time parameter like it is in dbus.

Alternatively, if the system service is a "leaf" package that is
sufficiently isolated from the rest of the system (doesn't use D-Bus,
doesn't need to share any files or sockets with other processes, doesn't
need to store long-term state, doesn't need configuration files that are
writeable by the service itself) then it can use systemd's DynamicUser
feature.

Using games:games is probably unsuitable for upstream in any case,
because the games uid and gid are guaranteed to exist *on Debian*,
but many distros have fewer pre-created uids and gids than we do, so
I'm confident that there will be at least one major distro where users
and groups with those names are not created.

    smcv