Apologies is this is not the right place to file such a bug, no owner can be determined for '/etc/env.d/90games' /usr/games/bin is at present stuffed into $PATH for all users, regardless of their group settings. This causes issue for some tools, such as 'git' in the process of resolving sub-commands when the user is not in the 'games' group, and this breaks all git aliases. > [alias] > foo = "!f(){ echo "HELLO" }; f" git foo fatal: cannot exec 'git-foo': Permission denied git moo fatal: cannot exec 'git-moo': Permission denied strace -f -e trace=file git foo execve("/usr/bin/git", ["git", "foo"], [/* 56 vars */]) = 0 ... Process 897251 attached [pid 897251] execve("/usr/libexec/git-core/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/home/kent/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/usr/local/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/usr/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/opt/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/git-foo", ["git-foo"], [/* 56 vars */]) = -1 ENOENT (No such file or directory) [pid 897251] execve("/usr/games/bin/git-foo", ["git-foo"], [/* 56 vars */]) = -1 EACCES (Permission denied) fatal: cannot exec 'git-foo': Permission denied --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=897251, si_status=128, si_utime=0, si_stime=0} (Child exited) --- Fortunately, its reasonably simple to solve this issue. 1. remove the path assignment from /etc/env.d/90games 2. eselect env update 3. insert the following as /etc/profile.d/90games.sh ------------------------------------------------------ groups | grep -m 1 -q 'games'; is_games=$? if [ $is_games == 0 ]; then PATH="${PATH}:/usr/games/bin/" fi ---------------------------------------------------- Tested, works for me.
Well, it seems the /etc/env.d/90games file , as well as the "games" group is created by the games.eclass, which seems broken in ways I don't even want to begin to explain how much my head hurts after seeing that. Yuck. Anyhow. The guys in charge of that : {vapier,wolf31o2,mr_bones_}@gentoo.org -> games@gentoo.org Some thoughts on the matter is it might be nicer to have a games-env package like kde-env that does this, at least it'd be somewhat cleaner and less "magical" You /could/ handle this in baselayout if you really wanted to, maybe even via a use flag if you really hated game people.
(In reply to comment #0) > This causes issue for some tools, such as 'git' in the process of resolving > sub-commands when the user is not in the 'games' group, and this breaks all > git aliases. Which ones (besides git)? > > Fortunately, its reasonably simple to solve this issue. > > > 1. remove the path assignment from /etc/env.d/90games > 2. eselect env update > 3. insert the following as /etc/profile.d/90games.sh > ------------------------------------------------------ > groups | grep -m 1 -q 'games'; > is_games=$? > > > if [ $is_games == 0 ]; then > PATH="${PATH}:/usr/games/bin/" > fi > > ---------------------------------------------------- > > Tested, works for me. ok (In reply to comment #1) > Well, it seems the > > /etc/env.d/90games file , as well as the "games" group is created by the > games.eclass, which seems broken in ways I don't even want to begin to > explain how much my head hurts after seeing that. > > Yuck. Or just fix git?!
(In reply to comment #2) How git behaves in this instance is rational. Consider: Set all paths in $PATH to not be accessible. Which is true: that there are no binaries in PATH ? Or that all binaries that *are* in PATH are not accessible? Git cannot see if those binaries do or do not exist, so it reports exactly that it has not the permission to know. Rationally: If you have a directory in PATH, then it follows that programs should check those directories for PATH. Git team would, upon seeing this bug, conclude the problem is you have a value in PATH which you in truth, shouldn't have in path. Because what sane person would put a path in $PATH if they could not access that directory, and then expect it to just be ignored? Sure, Git *could* be more helpful about the error it gives, but that wouldn't solve the problem.
Just skip all invalid $PATH fragments is a quite sane behaviour, implemented in every shell and which(1). Consider nonexistent directories like /usr/local/...,/opt/bin not mounted directories like /usr /opt ~/bin or not accessible not belonging to staff, Failing in such an situation is just stupid.
(In reply to comment #4) > Just skip all invalid $PATH fragments is a quite sane behaviour, > implemented in every shell and which(1). > > Consider nonexistent directories like /usr/local/...,/opt/bin > not mounted directories like /usr /opt ~/bin > or not accessible not belonging to staff, > > Failing in such an situation is just stupid. Perhaps. But even if I concede that Git could be improved to work in this way, I still argue: 1. It doesn't make sense to add /usr/games/bin to $PATH for users not in the games group. ( Just as only root sees /usr/sbin and /sbin ) 2. Creating this node in /etc/env.d/ using an eclass , and creating uid/gid, in the eclass seems like a wrong approach. At very least, #2, confuses one about the origin of files and configuration, and adds the likelihood cruft lies around after all games packages are gone. grep games /etc/passwd games:x:36:35:added by portage for gnugo:/usr/games:/bin/bash ^ rather confusing. as is: qfile /etc/env.d/90games # no results. I am aware this is starting to look like a seperate bug request, but this is sort-of in the line of "finding a working solution" ( as part of the problem was not knowing where to report the problem in the first place )
Do you think it's necessary to take care of this, given the approach of bug 417383 ...you could easily overwrite that files and have it config-protected.
Necessary, no. Git has since ceased tripping up on EACCES So it becomes a less pragmatic concern, and more an technical concern. Fundamentally I don't see the value of having a PATH that is expected *not* to be readable in PATH for all users. Though I can see how patching it based on groups membership may be misguided, maybe end user chmodded their game directory to be a+rx? So I think Having a commented out bit of logic in the ENV file for keen users would be enough, especially now config-protect will be expected to work. Also, an alternative way to codify it would be: if [[ -r $GAMES && -x $GAMES ]]; then PATH="$PATH:$GAMES" fi Which I'd imagine would work in slightly more usecases than the previous sample I posted, and accounts for people who chmod a+rx So that form could be commented in the source if you want to go that way.
commit 38f865c27d1f2560afb48efd2b7b105c1278c4b5 Author: Jeff King <peff@peff.net> Date: Fri Mar 30 03:52:18 2012 -0400 run-command: treat inaccessible directories as ENOENT ... -> v1.7.10.1 Last affected version was removed on 5-Dec-2013 And unaffected versions have been stable since 15-Jan-2013
(In reply to Kent Fredric from comment #7) > > if [[ -r $GAMES && -x $GAMES ]]; then > PATH="$PATH:$GAMES" > fi > I don't understand what that is supposed to do. $GAMES is not set anywhere.
(In reply to Julian Ospald (hasufell) from comment #9) > (In reply to Kent Fredric from comment #7) > > > > if [[ -r $GAMES && -x $GAMES ]]; then > > PATH="$PATH:$GAMES" > > fi > > > > I don't understand what that is supposed to do. $GAMES is not set anywhere. I meant as example. Was just too lazy to write out the PATH in full. if [[ -r "/usr/games/bin" && -x "/usr/games/bin" ]]; then PATH="$PATH:/usr/games/bin" fi M. I just spent the effort saved anyway :(
I just added a link to this bug in the envd file. Guess we can close this as WORKSFORME or OBSOLETE then.
