Citing the relevant part of 20151011 Council meeting summary [1]: "1. Decide that games should not be owned by a games group, and that in the default configuration users should not have to be in the games group to run games." Motion accepted with 6 yes and 1 abstention [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
commit 3d239d4e470c8f0c99339649ec74c4bdf86cf98f (HEAD -> master, origin/master, origin/HEAD) Author: Austin English <wizardedit@gentoo.org> AuthorDate: Tue Jun 28 03:43:09 2016 -0500 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Tue Jun 28 13:31:36 2016 +0000 games-emulation/dosbox: remove games eclass and convert to EAPI 6 Gentoo-Bug: https://bugs.gentoo.org/566498 Gentoo-Bug: https://bugs.gentoo.org/587382 Package-Manager: portage-2.2.28 Closes: https://github.com/gentoo/gentoo/pull/1777 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> games-emulation/dosbox/dosbox-0.74-r2.ebuild | 46 ++++++++++++++++++++++++++++++++++++++++++++++ games-emulation/dosbox/dosbox-9999.ebuild | 12 ++++++------ 2 files changed, 52 insertions(+), 6 deletions(-) create mode 100644 games-emulation/dosbox/dosbox-0.74-r2.ebuild
*** Bug 587382 has been marked as a duplicate of this bug. ***
I think this is a mistake likewise removing /usr/games and the games eclass is extremely questionable! I'd like to cite the Debian Policy here, why these game-specific features make a lot of sense: "The permissions on /var/games are mode 755, owner root and group root. Each game decides on its own security policy. Games which require protected, privileged access to high-score files, saved games, etc., may be made set-group-id (mode 2755) and owned by root:games, and use files and directories with appropriate permissions (770 root:games, for example). They must not be made set-user-id, as this causes security problems. (If an attacker can subvert any set-user-id game they can overwrite the executable of any other, causing other players of these games to run a Trojan horse program. With a set-group-id game the attacker only gets access to less important game data, and if they can get at the other players' accounts at all it will take considerably more effort.) Some packages, for example some fortune cookie programs, are configured by the upstream authors to install with their data files or other static information made unreadable so that they can only be accessed through set-id programs provided. You should not do this in a Debian package: anyone can download the .deb file and read the data from it, so there is no point making the files unreadable. Not making the files unreadable also means that you don't have to make so many programs set-id, which reduces the risk of a security hole. As described in the FHS, binaries of games should be installed in the directory /usr/games. This also applies to games that use the X Window System. Manual pages for games (X and non-X games) should be installed in /usr/share/man/man6." Especially the stated FHS should be regarded as inevitable standard, Gentoo breaking with this by council decision is indefensible!!!
(In reply to Simon from comment #3) > I think this is a mistake likewise removing /usr/games and the games eclass > is extremely questionable! > I'd like to cite the Debian Policy here, why these game-specific features > make a lot of sense: > > [...] > > Especially the stated FHS should be regarded as inevitable standard, Gentoo > breaking with this by council decision is indefensible!!! First, "Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it." https://devmanual.gentoo.org/general-concepts/filesystem/index.html#fhs Second, it is under consideration for the FHS itself to deprecate the special treatment of games. See https://bugs.linuxfoundation.org/show_bug.cgi?id=766#c4 (which is currently tagged for FHS 3.1). Especially: "The usage of /usr/lib/games and /usr/share/games has been deprecated in favour of treating games like any other packages installed on the system and installing them to the standard directories under /usr. The associated paths will be deprecated in a future revision of this standard." This very much coincides with (or goes even further than) our current policy: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games
FHS doesn't say that general game files need to be installed under the games group, only high score files and the like. We're also not banning the use of /usr/share/games entirely, it's still allowed if upstream uses that and it's non-trivial to change.
(In reply to comments #4, #5) >Second, it is under consideration for the FHS itself to deprecate the special >treatment of games. Ah ok i didn't know that future standard. ^^ > FHS doesn't say that general game files need to be installed under the games > group, only high score files and the like. Yes but with the set-group-id flag as stated in the Debian Policies that makes a lot of sence and should be concidered standard behaviour in a new games.eclass, otherwise high score files are manipulable.
Few more points which I think hasn't been repeated here. (In reply to Simon from comment #3) > Games which require protected, privileged access to high-score files, saved > games, etc., may be made set-group-id (mode 2755) and owned by root:games, > and use files and directories with appropriate permissions (770 root:games, > for example). [...] This is achieved via the 'gamestat' group these days. We can't use 'games' like every other distribution out there because of the historical 'games' group abuse which this bug aims to kill. There is the full explanation out there somewhere but long story short, the cited Debian policy assumes that *no users* belong to games group, while in Gentoo historically all users *needed* to belong to the group to be able to run games. The result of combining two incompatible uses of the group resulted in a huge security mess, and rendered the standard use of 'games' group impossible. That's why we had to add 'gamestat'. > As described in the FHS, binaries of games should be installed in the > directory /usr/games. This also applies to games that use the X Window > System. Manual pages for games (X and non-X games) should be installed in > /usr/share/man/man6." > > Especially the stated FHS should be regarded as inevitable standard, Gentoo > breaking with this by council decision is indefensible!!! I should add that FHS used /usr/games, not /usr/games/bin as Gentoo did. So Gentoo did violate FHS in the past, and this (yet another) abuse rendered the correct use of /usr/games impossible to achieve without causing issues with the past use.
[after mid-air collision] (In reply to Simon from comment #6) > Yes but with the set-group-id flag as stated in the Debian Policies that > makes a lot of sence and should be concidered standard behaviour in a new > games.eclass, otherwise high score files are manipulable. We aren't much different from Debian there. Debian: "The permissions on /var/games are mode 755, owner root and group root." Gentoo: "Directories /usr/share/games [and] /var/games which are shared by multiple packages must have owner root:root and permissions 755 (i.e., the default)." This is exactly the same, as far as /var/games is concerned. Debian: "Games which require protected, privileged access to high-score files, saved games, etc., may be made set-group-id (mode 2755) and owned by root:games, and use files and directories with appropriate permissions (770 root:games, for example). They must not be made set-user-id, as this causes security problems. (If an attacker can subvert any set-user-id game they can overwrite the executable of any other, causing other players of these games to run a Trojan horse program. With a set-group-id game the attacker only gets access to less important game data, and if they can get at the other players' accounts at all it will take considerably more effort.)" Gentoo: "Games that need privileged access to shared high-score or game state files can be installed setgid (mode g+s or 2755). Group "gamestat" with gid 36 (but not the "games" group) should be used for them. The files for state/scores should then be created in /var/games or a subdirectory of it and have appropriate owner and permissions (root:gamestat, mode g+w)." The only difference there is that we use gamestat as group, whereas other distros (including Debian) use games. (We cannot use the games group for setgid access, because with games.eclass it previously had a different purpose.)
Ahh ok didn't know about gamestat, thanks for the explanations. ;)
