As decided by the Council in its 20140812 meeting, every developer is allowed to commit and maintain games ebuilds. Furthermore: - There is consensus amongst council members that specific policies (e.g., games group, /usr/games hierarchy, and games.eclass) should be settled by the QA team. There are several problems that prevent installation of a games package if it does not follow the games team's policy that only users in the games group are allowed to run games: 1. Currently prepgamesdirs() in games.eclass changes ownership of directories to root:games and mode to 0750. Unfortunately, this is also done for top-level directories that are shared by multiple packages (mostly, these are the FHS locations): /usr/games /usr/games/bin /usr/games/lib* /usr/share/games /var/games /etc/games games.eclass should leave permissions of these directories alone, i.e. they should have ownership root:root and permissions 0755 (the default for directories, specified by PMS). For /opt, this has already been fixed: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/games.eclass?r1=1.135&r2=1.136 (Of course, it is o.k. if a package changes ownership and permissions of a subdir that it uses exclusively.) 2. It is quite common for games to save shared scores or other state files under /var/games, and access them with the program (or a special helper) setgid to a low privilege group, usually called "games". Of course, this mechanism cannot work if regular users are in the same group. See bug 125902 for details. Therefore both the "games" group and gid 35 seem unsuitable for that purpose, as it can be expected that on many users' systems today, regular users will be in this group. Proposal: Introduce new group to allow setgid binaries accessing shared score/state files. I suggest the name "gamescores" and gid 36, which is free and adjacent to the existing "games" group's 35. (Note: Red Hat, SuSE, and Debian use gid 20, 40, and 60, respectively. These are all taken in Gentoo.) 3. We could also consider renaming the existing "games" group, because our usage of it differs from all other major distros. In bug 125902, "gamers" was suggested. The gid 35 could be kept.
Created attachment 394786 [details, diff] games.eclass: Leave ownership and permissions of common trees alone
I am told that some commands have problems displaying group names longer than 8 chars, so "gamescores" is too long (and it would sound like "games cores"). Simply "scores" then? Other suggestions?
instead, you could try a proper solution https://github.com/hasufell/games-overlay/blob/master/eclass/gamers.eclass
(In reply to Julian Ospald (hasufell) from comment #3) > https://github.com/hasufell/games-overlay/blob/master/eclass/gamers.eclass Sorry, but that eclass suffers from several severe problems: - Both uid 40 and gid 40 are already taken, so you cannot use them for the "gamers" user and group. - What purpose does it serve to create a "gamers" user? - /var/lib/games is a deprecated location. The FHS uses /var/games now. - "In order to play this game and access the variable data files, you have to be in the 'gamers' group." I fail to see how this is an improvement over the current situation, where users must be in the "games" group. Renaming the group won't help us.
(In reply to Ulrich Müller from comment #4) > (In reply to Julian Ospald (hasufell) from comment #3) > > https://github.com/hasufell/games-overlay/blob/master/eclass/gamers.eclass > > Sorry, but that eclass suffers from several severe problems: > - Both uid 40 and gid 40 are already taken, so you cannot use them for the > "gamers" user and group. That's a one-line fix. > - What purpose does it serve to create a "gamers" user? > - /var/lib/games is a deprecated location. The FHS uses /var/games now. That's irrelevant and a one-line fix too. > - "In order to play this game and access the variable data files, you have > to be in the 'gamers' group." I fail to see how this is an improvement > over the current situation, where users must be in the "games" group. > Renaming the group won't help us. Errm, you completely miss the purpose I think. ONLY variable game data has those permissions, NOTHING else. That's basically how any other distro does games stuff.
(In reply to Ulrich Müller from comment #4) > Sorry, but that eclass suffers from several severe problems: > - Both uid 40 and gid 40 are already taken, so you cannot use them for the > "gamers" user and group. In addition, this is not correct. Both functions just try another available gid/uid.
(In reply to Ulrich Müller from comment #4) > - What purpose does it serve to create a "gamers" user? It fixes the nethack bug.
If this wasn't clear... this eclass is NOT a substitute to games.eclass. The idea is: * drop games.eclass completely * handle games as any other ebuild * ONLY for games that install score/bones files etc, make those special permissions for score/bones files via gamers.eclass... also check bug 125902
(In reply to Julian Ospald (hasufell) from comment #5) > Errm, you completely miss the purpose I think. ONLY variable game data has > those permissions, NOTHING else. But users still have to be members of the "gamers" group, otherwise they cannot write the variable game data. That's only a new name for the group, but otherwise not much different from what the current games.eclass does. > That's basically how any other distro does games stuff. Far from it. For example, Debian policy is this: https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11 In a nutshell: Their /var/games directory is owned by root:root with mode 755, subdirs are owned by root:games (and g+w). Programs accessing variable game data are owned by root:games and have the setgid bit set. (And users are never members of the games group.) (In reply to Julian Ospald (hasufell) from comment #7) > > - What purpose does it serve to create a "gamers" user? > > It fixes the nethack bug. I don't see any reference to the gamers user in the nethack ebuild: https://github.com/hasufell/games-overlay/blob/master/games-roguelike/nethack/nethack-3.4.3-r2.ebuild
(In reply to Ulrich Müller from comment #9) > (In reply to Julian Ospald (hasufell) from comment #5) > > Errm, you completely miss the purpose I think. ONLY variable game data has > > those permissions, NOTHING else. > > But users still have to be members of the "gamers" group, otherwise they > cannot write the variable game data. Yes, what's the problem? > That's only a new name for the group, > but otherwise not much different from what the current games.eclass does. > The eclass doesn't change ownership/permissions of _anything_ except the variable games data. As such it is fundamentally different than games.eclass and solves related security issues, including the nethack bug. > > That's basically how any other distro does games stuff. > > Far from it. For example, Debian policy is this: > https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11 > > In a nutshell: Their /var/games directory is owned by root:root with mode > 755, subdirs are owned by root:games (and g+w). Programs accessing variable > game data are owned by root:games and have the setgid bit set. (And users > are never members of the games group.) > > That's another approach, yes. Why do you prefer this one? > (In reply to Julian Ospald (hasufell) from comment #7) > > > - What purpose does it serve to create a "gamers" user? > > > > It fixes the nethack bug. > > I don't see any reference to the gamers user in the nethack ebuild: > https://github.com/hasufell/games-overlay/blob/master/games-roguelike/ > nethack/nethack-3.4.3-r2.ebuild You are right, the user wouldn't strictly be needed.
Can we please stop discussing unrelated approaches here? This bug is about the proposal in comment #0, items 1 and 2 (and maybe 3, but only if there is consensus for it). To clarify, this proposal is neither meant as a replacement of games.eclass, nor as a competition for any future gamers.eclass. The sole purpose is to allow maintainers to follow upstream preferences for their packages, i.e. install setgid binaries to access their score files, instead of requiring users to be in the games group.
(In reply to Ulrich Müller from comment #11) > Can we please stop discussing unrelated approaches here? This bug is about > the proposal in comment #0, items 1 and 2 (and maybe 3, but only if there is > consensus for it). > > To clarify, this proposal is neither meant as a replacement of games.eclass, > nor as a competition for any future gamers.eclass. The sole purpose is to > allow maintainers to follow upstream preferences for their packages, i.e. > install setgid binaries to access their score files, instead of requiring > users to be in the games group. It is not unrelated. You just seem unwilling to discuss this openly, neither do you really seem interested in understanding the approach.
(In reply to Julian Ospald (hasufell) from comment #12) > You just seem unwilling to discuss this openly, neither do you really seem > interested in understanding the approach. You know what? Instead of requesting a QA decision for a consistent policy, I could just implement the approach described in comment #0 and comment #9 in my packages. Nothing in our policy prevents a maintainer from creating a new group in his ebuilds.
This has been accepted unanimously by the QA team in today's meeting: - Directories /usr/games, /usr/games/bin, /usr/games/lib*, /usr/share/games, /var/games, /etc/games, and /opt must be owned by root:root and have permissions 755 (i.e. the default). - A new group to allow setgid binaries to access shared score/state files will be created. The name of this group will be "gamestat".
I have sent an announcement to gentoo-dev-announce and committed the patch for games.eclass. QA team policy is documented in the wiki: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games
