[gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1.1: message body text --]
[-- Type: text/plain, Size: 2284 bytes --]

Hi all,
As decided by the Council in its 20140812 meeting [1], every developer
is allowed to commit and maintain games ebuilds. Furthermore:

| There is consensus amongst council members that specific policies
| (e.g., games group, /usr/games hierarchy, and games.eclass) should
|  be settled by the QA team.

In yesterday's meeting the QA team has unanimously accepted the
following policies (see bug 537580 for details):

1. Directories /usr/games, /usr/games/bin, /usr/games/lib*,
   /usr/share/games, /var/games, /etc/games, and /opt must be owned
   by root:root and have permissions 755 (i.e. the default).

This will require a small change in games.eclass, because currently
prepgamesdirs() changes ownership of these directories to root:games
and mode to 0750, so they are readable only by users that are members
of the "games" group. With attached patch, games.eclass will no longer
change permissions of the top-level directories (mostly, these are
identical to the FHS locations).

If a package needs access control, it can still change ownership
and permissions of individual files, or of a subdir that it uses
exclusively. Owner and permission bits of directories that are shared
by multiple packages should be left alone, though.

2. A new group to allow setgid binaries to access shared score/state
   files will be created. The name of this group will be "gamestat".

It is quite common for upstream packages to save shared scores or
other state files under /var/games, and access them with the program
(or a special helper) setgid to a low privilege group. In most
distros, that group is called "games" (see for example Debian's policy
in [2]).

Unfortunately, the "games" group (gid 35) cannot be used for that
purpose in Gentoo, because by the long-standing games.eclass policy it
was/is used to control access to games. Therefore, regular users on
many Gentoo systems will be in this group.

Gid 36 is available and can be used for the new "gamestat" group.
I don't think that we need a new eclass for this; creation of the
group would be simply one line in pkg_setup():

    enewgroup gamestat 36

Ulrich

[1] http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt
[2] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.11


[-- Attachment #1.2: games.eclass.patch --]
[-- Type: text/plain, Size: 739 bytes --]

--- games.eclass	21 Nov 2014 21:47:16 -0000	1.159
+++ games.eclass	24 Jan 2015 19:26:16 -0000
@@ -246,10 +246,11 @@
 			[[ ${dir} = ${GAMES_STATEDIR} ]] && mode=o-rwx,g+r
 			find "${D}/${dir}" -type f -print0 | xargs -0 chmod $mode
 
-			# common trees should not be games owned #264872
-			if [[ ${dir} == "${GAMES_PREFIX_OPT}" ]] ; then
-				fowners root:root "${dir}"
-				fperms 755 "${dir}"
+			# common trees should not be games owned #264872 #537580
+			fowners root:root "${dir}"
+			fperms 755 "${dir}"
+			if [[ ${dir} == "${GAMES_PREFIX}" \
+						|| ${dir} == "${GAMES_PREFIX_OPT}" ]] ; then
 				for d in $(get_libdir) bin ; do
 					# check if dirs exist to avoid "nonfatal" option
 					if [[ -e ${D}/${dir}/${d} ]] ; then

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

>>>>> On Thu, 19 Feb 2015, Ulrich Mueller wrote:

> In yesterday's meeting the QA team has unanimously accepted the
> following policies (see bug 537580 for details):

> 1. Directories /usr/games, /usr/games/bin, /usr/games/lib*,
>    /usr/share/games, /var/games, /etc/games, and /opt must be owned
>    by root:root and have permissions 755 (i.e. the default).

> This will require a small change in games.eclass, because currently
> prepgamesdirs() changes ownership of these directories to root:games
> and mode to 0750, so they are readable only by users that are members
> of the "games" group. With attached patch, games.eclass will no longer
> change permissions of the top-level directories (mostly, these are
> identical to the FHS locations).

> [...]

> 2. A new group to allow setgid binaries to access shared score/state
>    files will be created. The name of this group will be "gamestat".

The change to games.eclass has been committed now, and the policy is
documented here:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

When this becomes more widespread, what action are users urged to take
in order to "migrate" to the new system? Should our everyday user
account be removed from the `games` group, and the group should be
removed altogether?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJU5/muAAoJEJUrb08JgYgHSMMH/i6WPhk4gsQlFlMZVarsXrne
/uyiFJ/IdQZUOWwgBH1Vl0WI55hPaqYKY2Myxv3tzFv2TDvAPa4NCZNZUBC1mPU0
d/JMhtPRTb74e3S/xy9yurwtprSIY1T843MO3/TUfEg6WS+oJnht4CqniZfYuMyl
9pqIW3XT+225TUnWSzsoaKcxGcORRtTBibUqNadDzCgkOfbtXrPx/FldwDySGAkW
rNm0Q6yRbnZX+drwZbQAr33LjtfjkJKE52mRciO7UzHeRT8jECX3pdnQ+4eNxRsW
+voNagAeqvisdi/zz6iKLaeUUb9TMhTnsk+5QK2TTP6kdMJeTByJXjHYGVMzZlQ=
=M4Fe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

>>>>> On Fri, 20 Feb 2015, Daniel Campbell wrote:

> When this becomes more widespread, what action are users urged to
> take in order to "migrate" to the new system? Should our everyday
> user account be removed from the `games` group, and the group should
> be removed altogether?

Currently, users need not take any action.

In the hypothetical case that games.eclass would be abandoned, the
"games" group would likely go away and should then be removed from
users' systems. However, with about 1000 ebuilds currently inheriting
games.eclass, I don't see that happening any time soon. There's a long
discussion on this topic in the nethack bug [1].

Personally, I think that controlling who is allowed to run certain
types of applications via group membership is a great idea. We should
introduce that approach for other applications too. How about an
"editors" group? Text editors are potentially dangerous because they
allow users to modify files. Therefore, the system administrator
should add only trusted users to the "editors" group so they can run
programs like emacs, nano, or vim from the app-editors category.

Ulrich

[1] https://bugs.gentoo.org/125902

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[hasufell]

Ulrich Mueller:
>>>>>> On Thu, 19 Feb 2015, Ulrich Mueller wrote:
> 
>> In yesterday's meeting the QA team has unanimously accepted the
>> following policies (see bug 537580 for details):
> 
>> 1. Directories /usr/games, /usr/games/bin, /usr/games/lib*,
>>    /usr/share/games, /var/games, /etc/games, and /opt must be owned
>>    by root:root and have permissions 755 (i.e. the default).
> 
>> This will require a small change in games.eclass, because currently
>> prepgamesdirs() changes ownership of these directories to root:games
>> and mode to 0750, so they are readable only by users that are members
>> of the "games" group. With attached patch, games.eclass will no longer
>> change permissions of the top-level directories (mostly, these are
>> identical to the FHS locations).
> 
>> [...]
> 
>> 2. A new group to allow setgid binaries to access shared score/state
>>    files will be created. The name of this group will be "gamestat".
> 
> The change to games.eclass has been committed now, and the policy is
> documented here:
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games
> 


Has this been done in cooperation with the games team? If not, why?

I think QA should make a clear statement if they are acting above a
projects head and why they had to do so, because this doesn't look like
a joint effort.

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

>>>>> On Sat, 21 Feb 2015, hasufell  wrote:

> Has this been done in cooperation with the games team? If not, why?

The games team is in CC of bug 537580 and no team member has
commented.

> I think QA should make a clear statement if they are acting above a
> projects head and why they had to do so, because this doesn't look
> like a joint effort.

As I said before, the QA team was asked by the council to settle the
policies on games group and /usr/games hierarchy.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[hasufell]

Ulrich Mueller:
>>>>>> On Sat, 21 Feb 2015, hasufell  wrote:
> 
>> Has this been done in cooperation with the games team? If not, why?
> 
> The games team is in CC of bug 537580 and no team member has
> commented.
> 
>> I think QA should make a clear statement if they are acting above a
>> projects head and why they had to do so, because this doesn't look
>> like a joint effort.
> 
> As I said before, the QA team was asked by the council to settle the
> policies on games group and /usr/games hierarchy.
> 

Ok, so the games team didn't resolve a 9 year old bug and several
non-trivial games.eclass problems and didn't communicate with either the
council, QA or the rest of the community about improving this?

What did the council say again about the functionality of the team?
What's the argumentation to not do anything, except deciding policies
over it's head?

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 597 bytes --]

Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell:

> What did the council say again about the functionality of the team?
> What's the argumentation to not do anything, except deciding policies
> over it's head?

functionality != willingness to interact with others

(seems to be a recurring problem, not everyone is equally prone to fill our 
mailboxes)

# of commits 1/12/2014 - 7/2/2015 in gentoo-x86
     15 Julian Ospald
    148 Alfredo Tupone
    251 Michael Sterrett

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/21/2015 01:35 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 20 Feb 2015, Daniel Campbell wrote:
> 
>> When this becomes more widespread, what action are users urged
>> to take in order to "migrate" to the new system? Should our
>> everyday user account be removed from the `games` group, and the
>> group should be removed altogether?
> 
> Currently, users need not take any action.
> 
> In the hypothetical case that games.eclass would be abandoned, the 
> "games" group would likely go away and should then be removed from 
> users' systems. However, with about 1000 ebuilds currently
> inheriting games.eclass, I don't see that happening any time soon.
> There's a long discussion on this topic in the nethack bug [1].

Okay, I'll check that out. It seems that if the group is ever deemed
obsolete, it would gain a news item or something similar.

> 
> Personally, I think that controlling who is allowed to run certain 
> types of applications via group membership is a great idea. We
> should introduce that approach for other applications too. How
> about an "editors" group? Text editors are potentially dangerous
> because they allow users to modify files. Therefore, the system
> administrator should add only trusted users to the "editors" group
> so they can run programs like emacs, nano, or vim from the
> app-editors category.
> 
> Ulrich
> 
> [1] https://bugs.gentoo.org/125902
> 
I hadn't thought of that! Would testing that idea require much beyond
creating the group, adding users, and chmodding the binaries? It seems
like it'd make a good USE option for those running servers with strict
permission needs. Then again, isn't that what LDAP or ACL are designed
to handle?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJU6UByAAoJEJUrb08JgYgH80wH/RSeCKr8xF4N0WsY4mgfjtRX
TOWSJI/SF+Cb38IHUupKLrP0Hyp1VQud9lI2KZTS6UVj/qUhJBdOHMT9TGeAzZvI
rVss1RQMcW/ZPNhBa0M5i/mgopKqWaFyoLY9BWEqBa1cg26Sh43PbeFpdpI7wChR
4ya3NO9Hzc2zLLlpMjMGCVsJsuM7E24YonD9poGYP3LmBw4ZGnNN00YWnLofFMlj
8M3tr0FZ7ALlAsB2sb7vMTkUSX4s3t442Li+D1ihocZMGMSQ+NeJOwhzQAMAU7nx
3kzwGg+IDaaYrDOL4FnuJ4tOtc8DGKlzLj71VvJnhsvkxh2Hn3ljUZYeaJqoY1A=
=7xED
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On 22 February 2015 at 15:35, Daniel Campbell <contact@sporkbox.us> wrote:

> >
> > Personally, I think that controlling who is allowed to run certain
> > types of applications via group membership is a great idea. We
> > should introduce that approach for other applications too. How
> > about an "editors" group? Text editors are potentially dangerous
> > because they allow users to modify files. Therefore, the system
> > administrator should add only trusted users to the "editors" group
> > so they can run programs like emacs, nano, or vim from the
> > app-editors category.
> >
> > Ulrich
> >
> I hadn't thought of that! Would testing that idea require much beyond
> creating the group, adding users, and chmodding the binaries? It seems
> like it'd make a good USE option for those running servers with strict
> permission needs. Then again, isn't that what LDAP or ACL are designed
> to handle?


Surely, there should be a straight foward way to do that via env.d +
package.env ?


env.d/restrict-editors.conf:

PORTAGE_INST_GID=editors  # this one exists
PORTAGE_INST_BIN="ug+x,o-x" # this one does not

or even

PORTAGE_BIN_DIR="/usr/bin/editors/"  # and then just set perms on the dir
itself, but this doesn't exist yet

+

package.env:

app-editors/* restrict-editors.conf


That combination would give the flexibility needed without having to have
portage implicitly bake all that logic into the whole tree. ( And it would
make it available to usecases we haven't envisioned yet )


I half considered Urlich to be joking .... but either way, I'm quite
capable of running with it and seeing where that leads us =).


Just seems that this type of isolation is really not necessary generally
and having it visible in a general purpose way is more prone to make life
difficult for both developers and users.

-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[-- Attachment #2: Type: text/html, Size: 3099 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On 02/21/2015 01:35 AM, Ulrich Mueller wrote:

>   Personally, I think that controlling who is allowed to run certain
>   types of applications via group membership is a great idea. We
>   should introduce that approach for other applications too. How
>   about an "editors" group? Text editors are potentially dangerous
>   because they allow users to modify files. Therefore, the system
>   administrator should add only trusted users to the "editors" group
>   so they can run programs like emacs, nano, or vim from the
>  app-editors category.
>

Protect the permissions on the files, not the editors - there's always
another way to get content into a file if you have write permission to it.
If you try to do that with a g+xo-x, then you're going to have to do the
same for every single command that can put output in a file (sed, curl,
wget, heck, anything that can be piped, every shell), and then your system
doesn't even need users anymore, because no user can do anything at all for
fear they might write to a file!

[-- Attachment #2: Type: text/html, Size: 1298 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

On 22 February 2015 at 18:06, Gordon Pettey <petteyg359@gmail.com> wrote:

>
> Protect the permissions on the files, not the editors - there's always
> another way to get content into a file if you have write permission to it.
> If you try to do that with a g+xo-x, then you're going to have to do the
> same for every single command that can put output in a file (sed, curl,
> wget, heck, anything that can be piped, every shell), and then your system
> doesn't even need users anymore, because no user can do anything at all for
> fear they might write to a file!



Indeed, which is why I think Ulrich may have been joking =).

Though conceptually its a useful question, because gentoo are not going to
anticipate all the security strictures a user is likely to want.

For instance, perhaps a sysadmin simply wants to lock up GCC and make,
having a straight forward way do to that in bashrc would help them achieve
that, without them having to dish out a full ACL/LDAP setup, and without
then needing to retouch the perms manually every install.

And that would be preferable IMO than a system wide proliferation of USE
flags to regulate such a thing.


-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[-- Attachment #2: Type: text/html, Size: 1977 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

>>>>> On Sat, 21 Feb 2015, Ulrich Mueller wrote:

> Personally, I think that controlling who is allowed to run certain
> types of applications via group membership is a great idea. We should
> introduce that approach for other applications too. How about an
> "editors" group? Text editors are potentially dangerous because they
> allow users to modify files. Therefore, the system administrator
> should add only trusted users to the "editors" group so they can run
> programs like emacs, nano, or vim from the app-editors category.

Oops, I forgot a smiley here. :)

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[hasufell]

On 02/21/2015 10:16 PM, Andreas K. Huettel wrote:
> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell:
> 
>> What did the council say again about the functionality of the team?
>> What's the argumentation to not do anything, except deciding policies
>> over it's head?
> 
> functionality != willingness to interact with others
> 
> (seems to be a recurring problem, not everyone is equally prone to fill our 
> mailboxes)
> 
> # of commits 1/12/2014 - 7/2/2015 in gentoo-x86
>      15 Julian Ospald
>     148 Alfredo Tupone
>     251 Michael Sterrett
> 

Sure, because I stopped working on the gentoo games in g-x86. I have
over 300 commits in gentoo-games overlay from that time period. Any
questions?

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[hasufell]

On 02/21/2015 10:16 PM, Andreas K. Huettel wrote:
> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell:
> 
>> What did the council say again about the functionality of the team?
>> What's the argumentation to not do anything, except deciding policies
>> over it's head?
> 
> functionality != willingness to interact with others
> 

So if a project ignores the community, the council, the QA team AND
violates GLEP39, we allow that, because they still do commits?

That isn't very logical.

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Rich Freeman]

On Wed, Feb 25, 2015 at 10:44 AM, hasufell <hasufell@gentoo.org> wrote:
> On 02/21/2015 10:16 PM, Andreas K. Huettel wrote:
>> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell:
>>
>>> What did the council say again about the functionality of the team?
>>> What's the argumentation to not do anything, except deciding policies
>>> over it's head?
>>
>> functionality != willingness to interact with others
>>
>
> So if a project ignores the community, the council, the QA team AND
> violates GLEP39, we allow that, because they still do commits?

Nobody is ignoring anything.  Council/QA has stepped in to clean things up.

What specific action are you advocating for which hasn't been done?

-- 
Rich

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[hasufell]

On 02/25/2015 04:47 PM, Rich Freeman wrote:
> On Wed, Feb 25, 2015 at 10:44 AM, hasufell <hasufell@gentoo.org> wrote:
>> On 02/21/2015 10:16 PM, Andreas K. Huettel wrote:
>>> Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell:
>>>
>>>> What did the council say again about the functionality of the team?
>>>> What's the argumentation to not do anything, except deciding policies
>>>> over it's head?
>>>
>>> functionality != willingness to interact with others
>>>
>>
>> So if a project ignores the community, the council, the QA team AND
>> violates GLEP39, we allow that, because they still do commits?
> 
> Nobody is ignoring anything.  Council/QA has stepped in to clean things up.
> 

You fixed a bug, you didn't fix the reason the bug was unhandled for 9
years.

> What specific action are you advocating for which hasn't been done?
> 

Start with enforcing GLEP39 which is still violated.

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Rich Freeman]

On Wed, Feb 25, 2015 at 10:52 AM, hasufell <hasufell@gentoo.org> wrote:
>
>> What specific action are you advocating for which hasn't been done?
>>
>
> Start with enforcing GLEP39 which is still violated.
>

I said "specific" - what do you mean by "enforcing GLEP39?"

-- 
Rich

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Diamond]

On Wed, 25 Feb 2015 16:44:28 +0100
hasufell <hasufell@gentoo.org> wrote:

> So if a project ignores the community, the council, the QA team AND
> violates GLEP39, we allow that, because they still do commits?

It looks like I can't edit
https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a bug?
gamesenv function looks outdated there. This function is seems like
done by adding RDEPEND="games-misc/games-envd" to packages in games
category now (according to games.eclass)?

Re: [gentoo-dev] Re: Policies for games dirs, new group "gamestat" for sgid binaries

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

>>>>> On Wed, 25 Feb 2015, Diamond  wrote:

> It looks like I can't edit
> https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a
> bug?

You can't because it is a project page. But I think you can leave a
message there on the talk page.

> gamesenv function looks outdated there. This function is seems like
> done by adding RDEPEND="games-misc/games-envd" to packages in games
> category now (according to games.eclass)?

I guess they have changed it because they want to avoid orphan files.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Sun, 22 Feb 2015 18:17:00 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> For instance, perhaps a sysadmin simply wants to lock up GCC and make,
> having a straight forward way do to that in bashrc would help them
> achieve that, without them having to dish out a full ACL/LDAP setup,
> and without then needing to retouch the perms manually every install.
> 

And why would anyone want to lock up GCC? If an attacker can execute
files he's created himself, he'll always find a way to get a compiler
(or at least an assembler) up and running.

And if he can't (which *would* be a sensible security feature for which
implementations are available, for example grSecurity's TPE) -- well,
then the GCC won't be of any help for the attacker, because he can't
execute the compiled binary.

Not that it matters. :)

-- 
Luis Ressel <aranea@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]