Bug#567033: Decide if we should continue recommending /usr/games

[Josh Triplett]

On Mon, Sep 11, 2023 at 07:11:30PM +0100, Simon McVittie wrote:
> Games are often written for performance more than correctness, and
> frequently do non-ideal things or have unfixed security issues. If we
> separate them into /usr/games and avoid putting that directory in root's
> PATH, then tab completion mistakes can't result in root accidentally
> running a game.
> 
> Similarly, I think (although I have no evidence) it's more common to
> install non-free games, and non-free game managers like Steam, than
> non-free utility/application software. If we put those in /usr/games, the
> root can't accidentally run those as a result of a tab-completion mistake.

Doing this by PATH alone seems of relatively limited value in a world in
which:
- Many (possibly *most*) users don't typically *log in* as root
  directly, and use something like sudo to explicitly run things as root
  instead, outside of recovery scenarios. And it seems fairly unlikely
  to explicitly "sudo somegame".
- Many non-text-based games may be launched from a GUI. And the
  text-based games seem unlikely to have massive unfixed security
  issues that arise just from *invocation*.
- On the average single-user system, most of the value is in the user's
  data *in their account*, and if something had a security issue
  allowing remote access, it'd likely be trivial to escalate to root
  anyway by any number of means, since that user ultimately has root
  access. If we have games with unfixed security issues, those need
  fixing (or sandboxing) *anyway* and putting them in /usr/games doesn't
  seem like a substantive mitigation.

Bug#567033: Decide if we should continue recommending /usr/games

[Alexandre Detiste]

Hi,

The bespoken machine of 2015 with 64GB of SSD has been repurposed
as a Buster (the "new" os at work) backporter box, but I'm still here.

I agree that the games in Debian - especially the free ones - don't
evolve that much,
don't grow so much, but on the "contrib engine + non-free assets" side
it goes in easily in the terabytes, all nicely and orderly managed with
gama-data-packager ...; so please keep the /usr/share/games dir;
so it can be split over a slow HDD or NFS.
(it's not really mandatory at boot even)

Next is /var/games , stuff managed by setgid/setuid binaries,
I would prefer to keep it as such.

Simon's argument about /usr/games are better than mine.

And yes, contents of this dir should generally be less trusted;
even proprietary .deb will install there.
( i.e. /usrgames/WorldOfGoo which works after deleting
is vendored libSDL, I guess a lot of others)

I would add about the usability of the shell when doing
autocomplete, I prefer to have /games separated,
it involves less mental context switch.

And things just work, and /usr/games is just an inode;
I don't see the advantage of getting rid of it.

FreeBSD is likely even more stuck in the past
with very few games to manage;
they can decide otherwise if it makes sense to them.

> libexec
(this scared me to propose that)


Greetings

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
>> Antoine Beaupré  writes:

>>> I get the argument against bad binaries not being in PATH but we have
>>> some tooling for that, don't we? /usr/libexec, no?

>> /usr/libexec isn't a replacement because it's not on any user's PATH.
>> /usr/games is intended to be added to a regular user's path but not
>> root's, which is a distinct use case.

> That's an odd argument to make: /usr/games isn't on any user's PATH
> either, is it?

It's common to add it, and I'm fairly sure we have documentation that
tells you to add it, whereas adding /usr/libexec to your PATH is a bug and
something that you should not do.  The binaries in /usr/libexec are not
intended to be invoked directly, may conflict with other binaries, may do
bizarre things when run from the command line, etc.

-- 
Russ Allbery (r...@debian.org)  

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
> > Antoine Beaupré  writes:
> >
> >> I get the argument against bad binaries not being in PATH but we have
> >> some tooling for that, don't we? /usr/libexec, no?
> >
> > /usr/libexec isn't a replacement because it's not on any user's PATH.
> > /usr/games is intended to be added to a regular user's path but not
> > root's, which is a distinct use case.
> 
> That's an odd argument to make: /usr/games isn't on any user's PATH
> either, is it?

% grep games /etc/profile /etc/login.defs
/etc/profile:  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
/etc/login.defs:ENV_PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 11:25:34, Russ Allbery wrote:
> Antoine Beaupré  writes:
>
>> I get the argument against bad binaries not being in PATH but we have
>> some tooling for that, don't we? /usr/libexec, no?
>
> /usr/libexec isn't a replacement because it's not on any user's PATH.
> /usr/games is intended to be added to a regular user's path but not
> root's, which is a distinct use case.

That's an odd argument to make: /usr/games isn't on any user's PATH
either, is it?

-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 19:57:16, Bill Allombert wrote:

[...]

> On the other hand, /usr/games allows:
> - priviledged accounts to omit /usr/games in their path (root does not have 
> it e.g)

I said it elsewhere but I'll repeat it here, if we want a separation
there, we already have another mechanism for that, and it's "private
binaries" in (say) /usr/libexec/

> - quickly find which games are installed on a system (ls /usr/games).

That's neat, but I doubt most users look for installed software with
`ls`. They are way more likely to use a GUI and there we have much
better mechanisms to sort things into buckets, other than "games" and
"not games".

In fact, I will argue that this makes games *harder* to find. If, for
some bizarre reason, a normal user ends up on the commandline to start a
game, they will type "gamename" (e.g. "freeorion") and will get an
unhelpful "command not found", because /usr/games typically won't be in
their PATH.

So this makes games easier to find for an extremely narrow class of
users who browse their filesystems looking for programs, I am not sure
it's worth it.

> - have a separate partitions for game data (which are amongst the largest 
> Debian package)

That, as far as I know, is not something /usr/games does at
all. e.g. here freeorion-data is all in /usr/share, not in /usr/games.

> - have a specific policy for /var/games

that also doesn't seem directly related to /usr/games, ie. you could
keep /var/games and not have /usr/games.

a.

-- 
La politique est l'art d'empêcher les gens de se mêler de ce qui les
regarde
- Paul Valéry

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:

> I get the argument against bad binaries not being in PATH but we have
> some tooling for that, don't we? /usr/libexec, no?

/usr/libexec isn't a replacement because it's not on any user's PATH.
/usr/games is intended to be added to a regular user's path but not
root's, which is a distinct use case.

Thanks, Simon and Bill.  I had forgotten about that point even though it
has come up before (just not in this bug).  I agree that's a more
compelling argument for keeping /usr/games.

-- 
Russ Allbery (r...@debian.org)  

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 19:11:30, Simon McVittie wrote:

[...]

> Disclosure: I am a co-maintainer with Alexandre of the game-data-packager
> package, which installs proprietary game data into /usr/share/games, some
> of it much larger than the vast majority of games we package in Debian; and
> I think converting game-data-packager and its various supported game engines
> for a transition from /usr/share/foo to /usr/share/games/foo would be quite
> annoying to achieve, without providing any significant benefit.

See oddly, I have no objection against /usr/share/games, because it's
kind of (more?) explicit it's game data and not executables.

I get the argument against bad binaries not being in PATH but we have
some tooling for that, don't we? /usr/libexec, no?

a.

-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Karl Popper

Bug#567033: Decide if we should continue recommending /usr/games

[Simon McVittie]

On Mon, 11 Sep 2023 at 10:19:13 -0700, Russ Allbery wrote:
> I am inclined to agree [with no longer recommending /usr/games];
> it's just one more thing for people to think about
> while packaging things, and I don't think it serves much of a useful
> purpose.  However, the bug log has a couple of concrete objections.

I have another possible reason to separate /usr/games, which I think is
potentially more compelling than either of the ones in the bug (I'm sorry,
I thought it was already common knowledge):

Games are often written for performance more than correctness, and
frequently do non-ideal things or have unfixed security issues. If we
separate them into /usr/games and avoid putting that directory in root's
PATH, then tab completion mistakes can't result in root accidentally
running a game.

Similarly, I think (although I have no evidence) it's more common to
install non-free games, and non-free game managers like Steam, than
non-free utility/application software. If we put those in /usr/games, the
root can't accidentally run those as a result of a tab-completion mistake.

Entertainment programs that are not strictly games (the ones we might
classify as "toys") have similar considerations.

Is this enough to justify the existence of /usr/games? I don't know; but
I think it's more likely to be enough to justify /usr/games than the other
reasons previously cited here?

In recent versions of Debian's Steam packaging (formerly the steam
package, now the steam-installer package) I've put a safety-catch on it:
if some important files in ~/.steam/root don't exist (indicating a new
installation), the wrapper script doesn't actually install or run any
proprietary code until the user has confirmed in a GUI dialog that they
actually wanted to install it. Similarly, the binary-only games that
game-data-packager can install have a wrapper script with a confirmation
dialog before the first run, similar to a clickthrough license, to avoid
accidents. That mitigates these being in privileged users' PATHs.

Valve's official Steam packaging in their third-party apt repository
(the steam-launcher package, currently maintained by me with a different
hat on) installs to /usr/bin and has no such safety-catch, but it does
require adding an apt source that will result in running Valve-supplied
maintainer scripts as root, so if you add that apt source you're already
completely trusting Valve anyway.

> Axel Beckert objected because games may conflict with other tools
> installed in /usr/bin.  I feel like this is already a bug and merging the
> two namespaces to force us to deal with that bug may be a feature in
> disguise, because having two binaries with entirely different purposes on
> the user's PATH is a recipe for confusion and problems.

I agree. I think it's silly that a PATH search for pacman can result in
running either a 2D maze game or Arch Linux's package manager, especially
if the two packages are co-installable!

I know we have a Policy requirement that packages do not contain both
/bin/foo and /usr/bin/foo, to ensure that merged-/usr is possible.

I thought we also had a requirement for names of executables in the
PATH to be unique between /{usr/,}bin and /{usr/,}sbin, but I can't find
it now. I know some packages like iproute2 install both /{usr/,}sbin/ip
and /{usr/,}bin/ip, which I think is OK if they are functionally equivalent,
but would be a bug if they were functionally different.

> This is similar the old multiuser timeshare use case for separating games
> back when they competed for resources with other uses of the system and
> administrators wanted to be able to stop people from running them until
> after hours.  I feel like this use case is exceptionally rare at this
> point, and I'm not sure it's worth the packaging thought to maintain a
> separation just for that.

Unlike Axel's namespace-splitting use-case, I think this is a positive
thing, but I'm unsure whether its small benefit is really worth its cost.

> Alexandre also requested keeping games data separate so that it could be
> moved out of the /usr partition because it could be quite large.

Again, I think this is a positive, but I'm unsure whether its benefit is
worth its cost. Perhaps it would be proportionate to say that games MAY
install into /usr/share/games, and leave it up to maintainers whether they
do so, with the suggestion that small games shouldn't bother but
maintainers of large games might want to consider it?

Disclosure: I am a co-maintainer with Alexandre of the game-data-packager
package, which installs proprietary game data into /usr/share/games, some
of it much larger than the vast majority of games we package in Debian; and
I think converting game-data-packager and its various supported game engines
for a transition from /usr/share/foo to /usr/share/games/foo would be quite
annoying to achieve, without providing any significant benefit.

smcv

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote:
> On 2018-06-14 11:42:22, Simon McVittie wrote:
> > Debian can choose to put games in the /.../games directories, or in the
> > standard directories /usr/bin, /usr/share etc., or any mixture of our
> > choice, orthogonal to whether/when we move to FHS 3.0.
> 
> It's been a while since this was discussed, but I have just learned of
> this issue, so sorry for bumping an old thread but...
> 
> I have recently learned that FreeBSD moved their games out of /usr/games
> and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all
> in the main PATH now, amazing no? :)
> 
> That happened in 2015:
> 
> https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80
> 
> I wonder if we should just do the same. I'm not sure I see the point of
> having all that stuff in a separate directory, personnally, but at least
> in this case we shouldn't needlessly diverge from upstream... although
> in terms of upstream for bsd-games, things are kind of hazy, at best,
> from what I understand.

I do not see any advantage over /usr/games.

On the other hand, /usr/games allows:
- priviledged accounts to omit /usr/games in their path (root does not have it 
e.g)
- quickly find which games are installed on a system (ls /usr/games).
- have a separate partitions for game data (which are amongst the largest 
Debian package)
- have a specific policy for /var/games

Cheers,
Bill

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 10:19:13, Russ Allbery wrote:

[...]

> I am inclined to agree; it's just one more thing for people to think about
> while packaging things, and I don't think it serves much of a useful
> purpose.  However, the bug log has a couple of concrete objections.

For the record, I actually read through those and didn't mean to restart
that thread: I figured people made their points and argued there thing
and there wasn't much to be said there, but now that you've made such a
nice summary, I can expand on the opinion I voiced above, I guess. :)

> Axel Beckert objected because games may conflict with other tools
> installed in /usr/bin.  I feel like this is already a bug and merging the
> two namespaces to force us to deal with that bug may be a feature in
> disguise, because having two binaries with entirely different purposes on
> the user's PATH is a recipe for confusion and problems.  The two bugs
> cited were:
>
> https://bugs.debian.org/845629
> https://bugs.debian.org/752114
>
> which are about a conflict between the game pacman and the package manager
> pacman.  The game pacman now appears to be orphaned but does indeed still
> ship /usr/games/pacman, and /usr/bin/pacman is provided by
> pacman-package-manager.

Yeah, I've always find this confusing, *especially* when you (like me)
have been adding /usr/games to your PATH since basically forever.

The truth is we really have one global binary namespace. Things that
move away from that tend to generate problems, or just live in their own
namespace (e.g. /usr/libexec or something). /usr/games is just a weird
exception that does not, in my opinion, deserve to exist anymore.

> There was also one request (from Alexandre Detiste) to retain this
> separation that, if I understood it correctly, was based on wanting to
> block access to games for children with accounts on the system.
>
> This is similar the old multiuser timeshare use case for separating games
> back when they competed for resources with other uses of the system and
> administrators wanted to be able to stop people from running them until
> after hours.  I feel like this use case is exceptionally rare at this
> point, and I'm not sure it's worth the packaging thought to maintain a
> separation just for that.

I also believe there are other ways to block access to files than move
them to a different directory, even if we *would* want to respond to
that use case. AppArmor comes to mind, for example.

> Alexandre also requested keeping games data separate so that it could be
> moved out of the /usr partition because it could be quite large.  This is
> another concern that I think in the subsequent eight years has become a
> bit less compelling due to the increase in the size of disks (which is
> only sort of keeping up with full commercial games, but is certainly
> keeping up with the games packaged in Debian).

I don't know about you folks, but the last time *I* played a game on
Debian, it was from steam, and all that crap ended up somewhere in my
$HOME, nevermind the :i386 architecture mess I had to slap on as well.

/usr/games certainly didn't help there... ;)

So yeah, maybe we could gamesmerge? I can see the GR coming aaah! ;)

a.

-- 
The difference between a democracy and a dictatorship is that in a
democracy you vote first and take orders later; in a dictatorship you
don't have to waste your time voting.
 - Charles Bukowski

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:

> I wonder if we should just do the same. I'm not sure I see the point of
> having all that stuff in a separate directory, personnally, but at least
> in this case we shouldn't needlessly diverge from upstream... although
> in terms of upstream for bsd-games, things are kind of hazy, at best,
> from what I understand.

I am inclined to agree; it's just one more thing for people to think about
while packaging things, and I don't think it serves much of a useful
purpose.  However, the bug log has a couple of concrete objections.

Axel Beckert objected because games may conflict with other tools
installed in /usr/bin.  I feel like this is already a bug and merging the
two namespaces to force us to deal with that bug may be a feature in
disguise, because having two binaries with entirely different purposes on
the user's PATH is a recipe for confusion and problems.  The two bugs
cited were:

https://bugs.debian.org/845629
https://bugs.debian.org/752114

which are about a conflict between the game pacman and the package manager
pacman.  The game pacman now appears to be orphaned but does indeed still
ship /usr/games/pacman, and /usr/bin/pacman is provided by
pacman-package-manager.

There was also one request (from Alexandre Detiste) to retain this
separation that, if I understood it correctly, was based on wanting to
block access to games for children with accounts on the system.

This is similar the old multiuser timeshare use case for separating games
back when they competed for resources with other uses of the system and
administrators wanted to be able to stop people from running them until
after hours.  I feel like this use case is exceptionally rare at this
point, and I'm not sure it's worth the packaging thought to maintain a
separation just for that.

Alexandre also requested keeping games data separate so that it could be
moved out of the /usr partition because it could be quite large.  This is
another concern that I think in the subsequent eight years has become a
bit less compelling due to the increase in the size of disks (which is
only sort of keeping up with full commercial games, but is certainly
keeping up with the games packaged in Debian).

-- 
Russ Allbery (r...@debian.org)  

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2018-06-14 11:42:22, Simon McVittie wrote:
> Debian can choose to put games in the /.../games directories, or in the
> standard directories /usr/bin, /usr/share etc., or any mixture of our
> choice, orthogonal to whether/when we move to FHS 3.0.

It's been a while since this was discussed, but I have just learned of
this issue, so sorry for bumping an old thread but...

I have recently learned that FreeBSD moved their games out of /usr/games
and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all
in the main PATH now, amazing no? :)

That happened in 2015:

https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80

I wonder if we should just do the same. I'm not sure I see the point of
having all that stuff in a separate directory, personnally, but at least
in this case we shouldn't needlessly diverge from upstream... although
in terms of upstream for bsd-games, things are kind of hazy, at best,
from what I understand.

(Kind of OT, but for example, wtf(6) is not in FreeBSD at all and comes
from NetBSD. It's maintained through a patch(1) in debian/patches on
bsd-games...)

Not sure what other BSDs are doing with their /usr/games, and I
understand we're not a BSD, but I figured I would at least document
what's going on on their side of that silly historical divide.

a.

-- 
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg

Bug#567033: Decide if we should continue recommending /usr/games

[Simon McVittie]

Control: unmerge 567033

On Fri, 11 Aug 2017 at 07:07:49 -0700, Sean Whitton wrote:
> The latest version of the FHS does not have /usr/games, so merging this
> with the bug about updating our FHS version.

Removing the games directories was considered in

and , but there
was no consensus. The FHS 3.0 as published by the Linux Foundation says
essentially the same things games as FHS 2.3:

> [/usr/]games  Games and educational binaries (optional)
> ...
> [/usr/share/]gamesStatic data files for /usr/games (optional)
> ...
> Similarly, a /usr/lib/games hierarchy may be used in addition to the
> /usr/share/games hierarchy if the distributor wishes to place some game
> data there.

(/usr/local/games is technically also mandatory, although I'm sure
that's an oversight and it was meant to be optional...)

Debian can choose to put games in the /.../games directories, or in the
standard directories /usr/bin, /usr/share etc., or any mixture of our
choice, orthogonal to whether/when we move to FHS 3.0.

smcv

Bug#567033: Decide if we should continue recommending /usr/games

[Josh Triplett]

On Fri, 11 Aug 2017 16:31:09 +0200 Axel Beckert  wrote:
> Sean Whitton wrote:
> > The latest version of the FHS does not have /usr/games, so merging this
> > with the bug about updating our FHS version.
> 
> Meh.
> 
> From my point of view we should continue to keep /usr/games/ for games
> as that helps to distinguish games from tools with the same name —
> which occassionally is necessary.

Whether we merge the two or not, I would argue that we should have
policy about packages not having the same binary name in /usr/games and
{,/usr}/{,s}bin , just as we now have policy about file conflicts
between / and /usr.

> Most prominent case: pacman — on the one hand the well-known game and
> on the other hand ArchLinux's package manager which is not (yet)
> packaged for Debian, but referred to in several tools packaged for
> Debian.
> 
> Removing /usr/games/ from Debian would reopen the following two bugs
> without trivial solutions, i.e. requiring to explicitly remove
> upstream code instead of just removing /usr/games/ from $PATH.
> 
> * neofetch: Starts the game pacman upon invocation
>   (https://bugs.debian.org/845629)
> 
> * needrestart: bug-script runs /usr/games/pacman when trying to use
>   ArchLinux's pacman package manager /etc/needrestart/hook.d/30-pacman
>   (https://bugs.debian.org/752114)

We could also fix these by renaming /usr/games/pacman. It doesn't seem
*completely* unreasonable to probe for "pacman" as the Arch package
manager, any more than probing for "dpkg" or "apt".

But at the same time, having a compile-time option to compile out
support for other package managers, and not installing hooks for other
package managers, seems reasonable as well.

Bug#787816: Bug#567033: Decide if we should continue recommending /usr/games

[Axel Beckert]

Hi,

Sean Whitton wrote:
> The latest version of the FHS does not have /usr/games, so merging this
> with the bug about updating our FHS version.

Meh.

>From my point of view we should continue to keep /usr/games/ for games
as that helps to distinguish games from tools with the same name —
which occassionally is necessary.

Most prominent case: pacman — on the one hand the well-known game and
on the other hand ArchLinux's package manager which is not (yet)
packaged for Debian, but referred to in several tools packaged for
Debian.

Removing /usr/games/ from Debian would reopen the following two bugs
without trivial solutions, i.e. requiring to explicitly remove
upstream code instead of just removing /usr/games/ from $PATH.

* neofetch: Starts the game pacman upon invocation
  (https://bugs.debian.org/845629)

* needrestart: bug-script runs /usr/games/pacman when trying to use
  ArchLinux's pacman package manager /etc/needrestart/hook.d/30-pacman
  (https://bugs.debian.org/752114)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE