Gnome games have group setuid protected highscore files. Gentoo uses group games for setuid protection, which is a group required to play other games and therefore the protection doesn't work for people in games group. $ ll /var/lib/games/mahjongg.ziggurat.scores -rw-rw-r-- 1 games games 0 Dec 11 00:02 /var/lib/games/mahjongg.ziggurat.scores jkarlson@schur: ~ $ ll /usr/bin/mahjongg -r-xr-s--x 1 root games 127720 Dec 11 00:02 /usr/bin/mahjongg Reproducible: Always
I have no idea what your problem is, please be more descriptive.
Gnome-games are setuid group, so the gain group privileges of the owning group to write highscores. This group privilege is coincidentally the one used used for restrict general access to other games, now all members of games group can write highscores. The highscore access group should be something that most users are not a member of.
I still don't understand why you want gnome games to be differently handled than any other games in gentoo ?
First of all other games are not playable by all as a rule, only the games group. -rwxr-x--- 1 root games 14209568 Sep 28 22:34 /usr/games/bin/wesnoth Also this allows users in games group to unexpectedly to feed arbitrary data to a program running with the privileges of an another user. Though not a probable security issue, but doesn't seem like a good practice to me. As far as I know other games do not use global high scores. This is comparable to having world writable files, which is a QA-issue, if you do not assume that people in games group are trusted users. Alternatives known to me: 1) Current situation: almost world writable files, and games playable by people not in games group (non-compliance to games project). 2) Write protect high score files: non-functional games. 3) Switch game executables' and high score files' group owner to eg. gamehighscores: games work as in other distros, non-compliance to games project. 4) Remove others' execution privileges for gnome-games executables: almost world writable files, at least partial compliance to games project.
Ok I see. We have to either choose for shared high-scores or no high-scores at all. We are not going to introduce another group for gnome games only, it would not make sense. We must fix permissions of executables but for the rest there is nothing much we can do.
Created attachment 259731 [details, diff] possible changes to gnome-games-2.30.2-r1.ebuild
Gnomine seems to survive the missing highscore files, it only says that you didn't make it to the highscore (which is displayed as empty).
I disagree with losing all highscore files. If I don't misremember, the usage of "games" group was oriented to add only "trusted" users to it due problems like this (writing allowed outside their home), then, fixing permissions would be enough to make gnome-games behave like the rest of games
Created attachment 265003 [details] comply to GAMES_STATEDIR At least we should comply to GAMES_STATEDIR, which seems to allow these sorts of files eg. diff attached.
I would like to have the opinion of other team members on this. Thanks :-)
This appears to be the bug for permissions set wrong for gnome-games, it looks like you're working on a more compressive solution, but here's a work-around until then: cd /usr/bin ls -la | grep games | awk '{print$9}' | xargs chmod o-x sloppy? yes. brute-force? definitely. Fixes executable permissions, so that only "group games" users can play games? Affirmative.
should be solved in 3.8 (at least, it relies on games.eclass much more)
