There has been some discussion about this topic already passed over time, while the Gentoo Gaming Team (GGT) stating, the current policy is wanted by the majority of Gentoo users, I felt hard to find much reference to this claim, which comes from somebody else than GGT themself (ok, there was one that I found). So, this poll is mostly an attempt to determine the feeling of the majority of Gentoo users on this opinion (to either verify or falsify the claim done by the GGT and to get a more reliable answer to that question).

For further information on the topic itself, you may visit the following URLs:

1.) The current way it's handled by the Gentoo Gaming Team (users have to be in the games group in order to play)

Currently, games maintained by the GGT are installed to /usr/games which in turn is chown root:games and chmod 750 (rwxr-x---) by default, making it inaccessible by anyone not in the games group (and not being root). Additionally there are similar file permissions on the executables and other support files, but that doesn't matter mostly, because neither reading nor entering that directory is possible for everyone not in the games group.

Advantage: The system administrator can choose, who can run (any) game. (However, It was pointed out, that this approach breaks down as soon as users start to install their local copies of the game in their home directories, where they have enough control over file ownership and execute permissions to run them - at least as long as /home (and some other directories like /tmp) is not mounted -o noexec).

Disadvantage: This approach imposes the problem, that any user in the games group can modify any game internal data like score files and for some games (nethack) even saved games from ANY user. Additionally, if programs have poor integrity checking on those files (nethack), this may even impose SEVERE SECURITY RISKS up to buffer overflows allowing of arbitrary code executing in the running instance of the game for a different user, when his saved game is modified accordingly.

2.) The way, most (all?) other distributions do handle that (games binaries are set group id games on execution)

Games are just installed to the FHS (i.e. to /usr, there is no /usr/games directory), games are owned by root:games like on Gentoo, but chmod 2751 (or -rwxr-s--x, i.e. set group id on execution) leading to the process executing the game on behalf of the user having changed it's effective group id to the group games. So the process has full access to directories with owner root:games and permission 770 (rwxrwx---), while the user running the program can't even ls the directory - a perfect situation to protect a score file from illegal changes by the users.

Disadvantage: The system administrator can no longer choose, who can run games (because no special permissions are required for that any longer).

Advantage: Because, now only games have access to certain problematic files, programs like nethack (who are the only executables legally allowed to write the files they later read) do no longer impose any security risks.

Disadvantage: However, games can still access (even write to) files owned by different games.

3.) A mixture of the "Gentoo" way and the "other distributions" way (i.e. create another group gamers with the meaning of the current games group and make the games group behave as in 2.)

Just take the advantages of 1.) and 2.) putting them together: make /usr/games be owned by root:gamers and mode 750 (rwxr-x---) and all files in /usr/games be owned by root:games and binaries having permission 2750 (rwxr-s--x) making them world executable and set games group on execution. Any user in group gamers can now run the games, but the games run in their own group.

Advantage: Both of 1.) and 2.)

Disadvantage: Game can still access (even write to) files owned by different games.

4.) Create a new group for each game and have each game set group id to that group

Like 3., but create one group for each game. So, instead of having one group games, there would be group nethack for nethack, freecraft for freecraft and so on.

Advantage: Those of 3, additionally, games can no longer access data belonging to other games effectively isolating each game from other games.

5.) Create TWO groups for each game and have each game set group id to one of that group and restrict access to it's binary to the other of the two groups.

Like 4., but additionally impose the semantic differences of groups "games" and "gamers" from answer 3 on a per package granularity.

Implementation would be most probably by creating a bin directory for each package and symlink it's executable to either /usr/bin or to /usr/games/bin. This special directory would then package-gamers-read only, while the executable itself would be package-games-sgid.

6.) I don't care / I don't know, what you're talking about / I don't play games at all / I'm not interested in security / etc.

Should be self-explanatory.

7.) I refuse this poll, because ... (please leave a comment)

If you refuse this poll itself altogether (maybe because you think, this post is pushing the result into any direction and hence not being neutral enough or maybe yet another way you would prefer isn't listed at all), please select answer 7 and give an explanation on that's wrong and in which way it should be changed.

Then adding a comment, that changing any of this variables would require reemerging of any games package in order to get the new desired behavior. Additionally, the games group should be renamed to gamers (or maybe better yet, a new gamers group be create -> because of change in group id ...) with all problems and solutions already having been discussed (like users already being part of group games and the possibility to provide a script update-games-group). However, that are implementation details to be discussed later, now, the important question is: In which direction should further discussion mainly go and what behavior actually has a possible user base of relevant size at all.

Not on the list, but I say "none of the above". I think the whole gamer/games thing should be dropped entirely and games should be treated like any other binary. Many (all?) of the KDE or GNOME, and many others don't receive any special treatment

As far is the first case (the "gamer" group)- most systems fall into 1 of 2 groups: 1) Productions system, that won't have games on them in the first place or 2) Home systems, where I can't really think of any practical use for only allowing people in a group to play.

As far as the second case (the "games" group): The whole setgid thing is more trouble than its worth. Just make each "playground" per-user in their home directory. Sure, players will be able to "cheat" with impunity (but for a single-player game they are only cheating themselves) and per-system highscores won't be possible, but the current solution is inadequate anyway. It would be better to have the games rewritten to do this via a daemon (possibly a d-bus service), which would not only be more secure, but could be extended to have per-network or per-domain score, saves via database, or high scores stored via LDAP . Of course while I believe this to be the most "correct" solution. its also the hardest to implement. System security is simply not worth the functionality setgid adds for games or the encumbrance it adds- it is, after all, only a game.

This brings to the discussion what qualifies as a game. Of course, everything in games-* categories are games, right?

DOSBox is inside games-emulation, but it can be used for non-gaming purposes, like running an old commercial or scientific program. In fact, once I had this need, and I was forced to add everyone to the "games" group just because of that.

But then... Do all games require such "special treatment"? I believe that only the games that actually need should be set-gid (like nethack, I guess).

Leave it as is. Gentoo was fine 8 years ago before they started changing everything around... for Thor's sake, just leave it be. It works!_________________"Giving money and power to government is like giving whiskey and car keys to teenage boys." - P. J. O'Rourke

I don't care too much about the "only users in the games group can play games" policy, just because it is inconsistent anyway (what about all these tiny kde games, emulators and so on, not to speak about browser games).

Yes, you can mount all user-writable directories with noexec. While this might be a solution in some cases, I think this is too restrictive for others (systems that are used for development). But without that, the current games policy is quite useless and causes more problems than it solves.

Some games are designed to be installed with the setgid bit (to some empty group with no members), so to me it seems to be the right thing just to follow the installation instructions from upstream, like most other distros do (suggestion #2). But I wouldn't be unhappy with having an extra "gamers" group (suggestion #3) either, I just don't care about that. _________________Unix philosophy: "Do one thing and do it well."systemd: "Do everything and do it wrong."

The more I think about it the more salahx's post makes sense. Where do you draw the line for a "games" group, if DOSBox is on one side and Wine + Firefox on the other? It makes more sense and less work to simply leave the special UIDs out unless there's a real need for them.

The 3rd option looks reasonable - the existing feature of selecting who plays games can be kept, while games which expect (e.g.) their score files to be read-only for other applications and users may still expect that under Gentoo.

A discussion on the need for the existing feature wouldn't need to take place now - I don't think, it is a good idea to remove this just because other distros aren't doing it and some games (nethack) have trouble with it.

Quote:

if programs have poor integrity checking on those files (...), this may even impose SEVERE SECURITY RISKS

Shouldn't that be a problem by itself?

Also, if it is changed this way, please make sure that a new group is chosen for setuid, or that warnings are issued on the updates that make the change - otherwise systems with users who are allowed to play games will give those users a way to use those security risks.

if programs have poor integrity checking on those files (...), this may even impose SEVERE SECURITY RISKS

Shouldn't that be a problem by itself?

Also, if it is changed this way, please make sure that a new group is chosen for setuid, or that warnings are issued on the updates that make the change - otherwise systems with users who are allowed to play games will give those users a way to use those security risks.

Ideally, the 'games group update script' would arrange for the 'games' group to get a new GID, and the 'gamers' group to get the old GID that previously belonged to the old 'games' group, then users who were previously members of the old 'games' group would now be members of the new 'gamers' group instead. I'm not sure how this would work in a NIS/YP set-up, but they already have problems with the Gentoo 'games' group (unless all the other systems in the NIS domain follow the Gentoo games policy)._________________Ebichu wa chiizu ga daisuki dechu!

we need to get nethack unmasked bug 12592 over 6 years old_________________A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

# if you want to use a different user/group than games.games,
# just add these two variables to your environment (aka /etc/profile)
export GAMES_USER=${GAMES_USER:-root}
export GAMES_USER_DED=${GAMES_USER_DED:-games}
export GAMES_GROUP=${GAMES_GROUP:-games}

adding variables to control the permissions "prepgamesdirs" function applies would be a thing to consider on top of that maybe?