What is currently considered the correct/recommended/best-practice use of the games-group...

  • As a "device group" for game-ports and joy-sticks, unassociated with the games-user (except for being one of the many groups the game-user probably would have to belong to) and with a (very) different GID than UID of the games-user...

  • Or as a "pair" together with the games-user – preferably with matching UID and GID – where the group lists users allowed to execute programs belonging to the games-user. This to limit what user is allowed to enjoy themselves.

Are there alternatives? Other names you've seen or think would work for a group for game-ports and joy-stick devices; for a group of users allowed to play; and/or user for running games as? (e.g. 'rec' for recreational) Do you think this could be a good idea or does it break tradition too much?

I'm toying with the idea of building/customizing my own distro, so I'm not encumbered with how other distros do it or what's most common... I'm more asking for what you've seen, what you've tried and what you think would work best.

I'm also interested for such experiences from users of other Unices too, after all most of them don't break down their devices quite as much as Linux does... Do they still have a games-group? How and for what is it used?

  • You realize in many companies they simply either strip out all games or not install them in the beginning. Thus the games ID is just not used. – mdpc Dec 20 '12 at 21:34

Before deciding what the user and group called games should be used for, you should figure out why you would want to have distinct users. What special permissions are associated to games?

  • Running games. There is usually no need for any privilege to run a game, beyond having a shell account. If you restrict users from running the games you've installed, they can install them on their own anyway.
  • Accessing gaming hardware. Hardware devices are rarely game-specific: you can plug in a MIDI keyboard on a game port, use a joystick to control a physical object, …
  • Participating in multi-user interactions — primarily storing high scores. This requires the game to run with elevated privileges if you don't want users to be able to edit the high score files with any editor or utility.
  • Installing and maintaining game programs.

It's rare to have access control related to running games and accessing gaming hardware (there may be access control to gaming peripherals, but it's not specific to their use for gaming). It's common to have access control related to high score files and game program installation.

It's a bad idea to make a game program setuid. Most games are not designed with security in mind, and there is often a way for the user who runs the game to modify arbitrary files or even run commands with the game's elevated permissions. If the game executable is setuid, this allows the user running the game to modify the game executable and turn it into a trojan which can then infect any other user who runs the game.

Thus the user owning the game executables must not be used to control who can run them, use peripherals or write high score files. It can be used to control who can install games. If you have a games user at all, its use would be to allow game administrators to sudo to the game-administrators user (a more explicit name) and maintain a /usr/games or /usr/local/games directory owned by game-administrators. Such game administrator can gain privileges of any user who plays these games, so game administrator privileges should be given out only to trustworthy people.

To control access to high score files, it is ok to make them owned by a group, which can be (and often is) called games. The games with shared high score files are then made setgid games. Do not use the games group for anything other than ownership of high scores and similar interaction files, and of game executables. Note in particular that the game executables must not be writable by the games group: they must have permissions rwxr-sr-x (2755). A user who manages to exploit a vulnerability in a setgid game will be able to modify high score files but cause no other mischief.

If you wish to restrict access to games to certain users, create a game-players group and make the directory containing the games accessible only to that group, i.e. make /usr/local/games (or wherever the games are) owned by game-administrators:game-players and mode rwxr-x--- (750).

  • Fun story: one of my best friends set his level to the highest level of an old MUD by updating the binary file with a hex editor. This in turn got him immortal status and then he was inspired to make his own MUD (where I met him and became heavily involved in programming there). He's also used hex editors for other .. ehm, non-dubious (?) things. But then again who hasn't? So yes you're right - you have to be very careful what they can modify and you have to think it out very carefully! – Pryftan Dec 25 '19 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.