1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 02/19/2015 06:19 AM, Ulrich Mueller wrote: |
5 |
> Hi all, As decided by the Council in its 20140812 meeting [1], |
6 |
> every developer is allowed to commit and maintain games ebuilds. |
7 |
> Furthermore: |
8 |
> |
9 |
> | There is consensus amongst council members that specific |
10 |
> policies | (e.g., games group, /usr/games hierarchy, and |
11 |
> games.eclass) should | be settled by the QA team. |
12 |
> |
13 |
> In yesterday's meeting the QA team has unanimously accepted the |
14 |
> following policies (see bug 537580 for details): |
15 |
> |
16 |
> 1. Directories /usr/games, /usr/games/bin, /usr/games/lib*, |
17 |
> /usr/share/games, /var/games, /etc/games, and /opt must be owned by |
18 |
> root:root and have permissions 755 (i.e. the default). |
19 |
> |
20 |
> This will require a small change in games.eclass, because |
21 |
> currently prepgamesdirs() changes ownership of these directories to |
22 |
> root:games and mode to 0750, so they are readable only by users |
23 |
> that are members of the "games" group. With attached patch, |
24 |
> games.eclass will no longer change permissions of the top-level |
25 |
> directories (mostly, these are identical to the FHS locations). |
26 |
> |
27 |
> If a package needs access control, it can still change ownership |
28 |
> and permissions of individual files, or of a subdir that it uses |
29 |
> exclusively. Owner and permission bits of directories that are |
30 |
> shared by multiple packages should be left alone, though. |
31 |
> |
32 |
> 2. A new group to allow setgid binaries to access shared |
33 |
> score/state files will be created. The name of this group will be |
34 |
> "gamestat". |
35 |
> |
36 |
> It is quite common for upstream packages to save shared scores or |
37 |
> other state files under /var/games, and access them with the |
38 |
> program (or a special helper) setgid to a low privilege group. In |
39 |
> most distros, that group is called "games" (see for example |
40 |
> Debian's policy in [2]). |
41 |
> |
42 |
> Unfortunately, the "games" group (gid 35) cannot be used for that |
43 |
> purpose in Gentoo, because by the long-standing games.eclass policy |
44 |
> it was/is used to control access to games. Therefore, regular users |
45 |
> on many Gentoo systems will be in this group. |
46 |
> |
47 |
> Gid 36 is available and can be used for the new "gamestat" group. I |
48 |
> don't think that we need a new eclass for this; creation of the |
49 |
> group would be simply one line in pkg_setup(): |
50 |
> |
51 |
> enewgroup gamestat 36 |
52 |
> |
53 |
> Ulrich |
54 |
> |
55 |
> [1] |
56 |
> http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt |
57 |
> |
58 |
> |
59 |
[2] |
60 |
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11 |
61 |
> |
62 |
|
63 |
When this becomes more widespread, what action are users urged to take |
64 |
in order to "migrate" to the new system? Should our everyday user |
65 |
account be removed from the `games` group, and the group should be |
66 |
removed altogether? |
67 |
-----BEGIN PGP SIGNATURE----- |
68 |
Version: GnuPG v2 |
69 |
|
70 |
iQEcBAEBCAAGBQJU5/muAAoJEJUrb08JgYgHSMMH/i6WPhk4gsQlFlMZVarsXrne |
71 |
/uyiFJ/IdQZUOWwgBH1Vl0WI55hPaqYKY2Myxv3tzFv2TDvAPa4NCZNZUBC1mPU0 |
72 |
d/JMhtPRTb74e3S/xy9yurwtprSIY1T843MO3/TUfEg6WS+oJnht4CqniZfYuMyl |
73 |
9pqIW3XT+225TUnWSzsoaKcxGcORRtTBibUqNadDzCgkOfbtXrPx/FldwDySGAkW |
74 |
rNm0Q6yRbnZX+drwZbQAr33LjtfjkJKE52mRciO7UzHeRT8jECX3pdnQ+4eNxRsW |
75 |
+voNagAeqvisdi/zz6iKLaeUUb9TMhTnsk+5QK2TTP6kdMJeTByJXjHYGVMzZlQ= |
76 |
=M4Fe |
77 |
-----END PGP SIGNATURE----- |