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

["P. J. McDermott" <pj@pehjota.net>]

On 2023-12-31 at 11:09, Simon McVittie wrote:
> 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.

Thank you Simon and Alexandre!  This is very helpful.  Sorry for taking
your time with such basic and perhaps lazy questions; as I said I don't
use systemd so I'm a little out of my depth in this area.

So I'll send a patch upstream to use _wesnoth:_wesnoth and add a
sysusers.d file, then do something similar in Debian.

I see systemd documentation recommends [1] the underscore convention.

[1]: https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html#Name

> 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.

Indeed Arch [2] is that one major distribution with a games group but no
games user.  Although interestingly, upstream uses [3] nobody:users, and
Arch installs [4] upstream's service file without changing that, but
they don't have a nobody user.  Apparently no one noticed/complained.

[2]: https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/blob/main/sysusers
[3]: https://github.com/wesnoth/wesnoth/blob/master/packaging/systemd/wesnothd.service.in
[4]: https://gitlab.archlinux.org/archlinux/packaging/packages/wesnoth/-/blob/main/PKGBUILD

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/