[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: