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.
