Re: Proposed changes to wesnoth-1.16 (fixes RC bug and autoremoval in boost1.83 transition)
On Fri, 29 Dec 2023 at 08:56:16 -0500, P. J. McDermott wrote:
> In particular, I'd like a review of the systemd and init.d commit, to
> confirm that games:games is the right user/group
I don't think this is right, thanks for asking for review on this.
The games group is defined in base-passwd and Policy as an appropriate
group for making older Unix-oriented games setgid games, so that they can
write to a system-wide high scores list or similar. I don't think running
a dedicated server is really the same use-case.
There is a games user in base-passwd, but no specific meaning is defined
for it, which makes me concerned that people will be repurposing this
username for purposes like "the user I log in as to run Steam".
If running a Wesnoth dedicated server is something we want to support as a
"first class citizen" use-case in the packaging system, as we do for some
other games like OpenArena and the Quake series, then I think it should
be using its own dedicated user/group pair, ideally _wesnoth:_wesnoth
or something. That way, if there is an exploitable vulnerability in the
Wesnoth server that lets an attacker run arbitrary code as the server user,
the attacker will not be able to use that access to interfere with other
games or other parts of the OS.
OpenArena uses the Debian-openarena user ID, which is part of an older
naming convention - if I was packaging OpenArena today, it would be running
as _openarena instead. The relevant Policy wording is:
When maintainers choose a new hardcoded or dynamically generated
username for packages to use, they should start this username with
an underscore
— https://www.debian.org/doc/debian-policy/ch-opersys.html#users-and-groups
(I have not done a more general review of this package and I am unlikely
to be able to do so any time soon, so please don't block on me.)
Thanks,
smcv
Reply to: