| 1 |
Hi all, |
| 2 |
As decided by the Council in its 20140812 meeting [1], every developer |
| 3 |
is allowed to commit and maintain games ebuilds. Furthermore: |
| 4 |
|
| 5 |
| There is consensus amongst council members that specific policies |
| 6 |
| (e.g., games group, /usr/games hierarchy, and games.eclass) should |
| 7 |
| be settled by the QA team. |
| 8 |
|
| 9 |
In yesterday's meeting the QA team has unanimously accepted the |
| 10 |
following policies (see bug 537580 for details): |
| 11 |
|
| 12 |
1. Directories /usr/games, /usr/games/bin, /usr/games/lib*, |
| 13 |
/usr/share/games, /var/games, /etc/games, and /opt must be owned |
| 14 |
by root:root and have permissions 755 (i.e. the default). |
| 15 |
|
| 16 |
This will require a small change in games.eclass, because currently |
| 17 |
prepgamesdirs() changes ownership of these directories to root:games |
| 18 |
and mode to 0750, so they are readable only by users that are members |
| 19 |
of the "games" group. With attached patch, games.eclass will no longer |
| 20 |
change permissions of the top-level directories (mostly, these are |
| 21 |
identical to the FHS locations). |
| 22 |
|
| 23 |
If a package needs access control, it can still change ownership |
| 24 |
and permissions of individual files, or of a subdir that it uses |
| 25 |
exclusively. Owner and permission bits of directories that are shared |
| 26 |
by multiple packages should be left alone, though. |
| 27 |
|
| 28 |
2. A new group to allow setgid binaries to access shared score/state |
| 29 |
files will be created. The name of this group will be "gamestat". |
| 30 |
|
| 31 |
It is quite common for upstream packages to save shared scores or |
| 32 |
other state files under /var/games, and access them with the program |
| 33 |
(or a special helper) setgid to a low privilege group. In most |
| 34 |
distros, that group is called "games" (see for example Debian's policy |
| 35 |
in [2]). |
| 36 |
|
| 37 |
Unfortunately, the "games" group (gid 35) cannot be used for that |
| 38 |
purpose in Gentoo, because by the long-standing games.eclass policy it |
| 39 |
was/is used to control access to games. Therefore, regular users on |
| 40 |
many Gentoo systems will be in this group. |
| 41 |
|
| 42 |
Gid 36 is available and can be used for the new "gamestat" group. |
| 43 |
I don't think that we need a new eclass for this; creation of the |
| 44 |
group would be simply one line in pkg_setup(): |
| 45 |
|
| 46 |
enewgroup gamestat 36 |
| 47 |
|
| 48 |
Ulrich |
| 49 |
|
| 50 |
[1] http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt |
| 51 |
[2] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11 |
Archives