Gentoo Archives: gentoo-dev

From: Daniel Campbell <contact@××××××××.us>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries
Date: Sat, 21 Feb 2015 03:21:33
Message-Id: 54E7F9B1.6000301@sporkbox.us
In Reply to: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries by Ulrich Mueller
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-----

Replies