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

Re: Proposed changes to wesnoth-1.16 (fixes RC bug and autoremoval in boost1.83 transition)



On Sun, Dec 31, 2023 at 12:45 AM P. J. McDermott <pj@pehjota.net> wrote:
>
> On 2023-12-29 at 14:55, Simon McVittie wrote:
> > 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 Simon for reviewing this change and correcting my understanding
> of Policy on this matter.  I agree that would be the best solution.  So
> postinst/prerm should adduser/deluser.
>
> 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.
>
> However, I guess none of my changes need to be reviewed now anyway.
> Vincent, it looks like you ignored all of my proposed changes and
> just uploaded a bare new upstream release?  Granted, it's nice to get
> something uploaded quickly since the package will be autoremoved from
> testing on Tuesday, and a couple of my proposed changes are incorrect/
> inappropriate.  But I thought at least the upstream regression patch
> backport, DEP-5 conversion and copyright update, removal of embedded JS
> library code copies, deprecated debian/*.tmpfile update, and font
> symlinks fix would be good to include.

Ah, sorry, I didn't see this thread before uploading wesnoth; I'll be
honest, I'm not keeping a close eye on my debian mail and I'm doing
the bare minimum to keep my packages in shape due to overall lack of
time recently. Indeed, I just wanted to close out the RC bug.

I took a quick glance at the diff. My personal threshold for repacking
source tarballs is higher than that of most other maintainers. I'm
inclined to not repack unless otherwise necessary (i.e. there's
non-DFSG-compatible stuff that needs to be removed). When it comes to
minified js, I'd rather just store a non-minified copy in
debian/missing-sources, leave the source tarball untouched, suppress
the lintian warning and move on. Otherwise please feel free to push
your changes to games-team/wesnoth on salsa. Thank you!

Regards,
Vincent


Reply to: