It's popped up on occasion; portage should be mangling the path so sbin ends up in it. Easy way to see this, sudo emerge ntp and watch if fail in enewuser since useradd can't be found.
The above description isn't that readable. But it really is anoying that sudo doesn't look in sbin dirs. Debian has that functionality as default, so should gentoo.
Someone on the forums pointed out that the 1.6.8_p8 ebuilds are removing /usr/local/bin from the secure path, but secure path seems to include /usr/local/bin if ROOTPATH is not set.
Clarification, do you want portage to mangle the path JUST for sudo, or always? The former is not really feasable, and the latter is just silly, IMHO.
according to the sudo documention: To prevent command spoofing, sudo checks "." and "" (both denoting current directory) last when searching for a com- mand in the user's PATH (if one or both are in the PATH). Note, however, that the actual PATH environment variable is not modified and is passed unchanged to the program that sudo executes. I've tested 1.6.8p9, and found it does comply with the documentation.
Indeed; sudo deliberately doesn't set the ROOT's PATH when using sudo. This is both documented in the sudo documentation and the various resources on the Internet (including Gentoo's sudo guide at http://www.gentoo.org/doc/en/sudo-guide.xml).
*** Bug 118847 has been marked as a duplicate of this bug. ***
*** Bug 133747 has been marked as a duplicate of this bug. ***
*** Bug 136697 has been marked as a duplicate of this bug. ***
*** Bug 146691 has been marked as a duplicate of this bug. ***
in case it's not clear from the discussion so far, it's not just $PATH that needs sanitizing. Summary of duplicate bug 146991 - this fails: export Z=foo emerge --oneshot tk
*** Bug 182955 has been marked as a duplicate of this bug. ***
*** Bug 188641 has been marked as a duplicate of this bug. ***
*** Bug 189417 has been marked as a duplicate of this bug. ***
*** Bug 198764 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > *** Bug 198764 has been marked as a duplicate of this bug. *** > I don't believe bug #198764 is a duplicate of bug #56407. In bug #198764, the INCLUDE variable *is* sanitized and sane, and set to exactly what it should be set to, and should *not* be removed by portage, due to it being used when compiling with icc. It's the exim package that incorrectly expects INCLUDE to be of the compiler specific form "-I/some/path". This can be fixed by the exim maintainer by explicitly setting INCLUDE= in Local/Makefile (until upstreams stops using all caps variable names for private variables). Can someone with access to do so reinstate bug #198764?
*** Bug 201995 has been marked as a duplicate of this bug. ***
*** Bug 204485 has been marked as a duplicate of this bug. ***
*** Bug 210099 has been marked as a duplicate of this bug. ***
*** Bug 211597 has been marked as a duplicate of this bug. ***
*** Bug 211882 has been marked as a duplicate of this bug. ***
*** Bug 215039 has been marked as a duplicate of this bug. ***
*** Bug 165804 has been marked as a duplicate of this bug. ***
Does su behave a different way than sudo ? In bug #165804 (it was long time ago, but IIRC ... ) i was logged in as user under X env in Debian, then compiling Gentoo from there. Thus, I logged in first as user, then did su or sudo, then did chroot. In comment #4, Peter Volkov advises me to try this: > BTW, for chroot personally I found solution to enter it with the following > command: > env -i chroot ${path} /bin/bash --login > this will recreate environment on entering chroot... HTH. After reading this bug, I think this workaround may help many people. I think he is right in saying the fix should be at the emerge level: emerge needs to read some env vars for various reasons, but, I wonder if it really should let them accessible for ebuild execution. In present case, I wish it did not; but long time ago, I remember I had to export LD_PRELOAD from user's .bashrc (and could not do that from the system wide /etc/bashrc for various reasons) to use a Socks Proxy (Microsoft gateway in the network I was using on these days) ... a case where I would wish emerge to keep env vars to let wget know about socks proxy ... so the solution is not as much trivial as I thought. an other example of variable to keep is USE. Still, all people attached to this bug could try this small WA, and report if it helps, or not, for their respective bugs. Mine was a specific cross-install stage problem; cant reproduce before I need to reinstall :)
*** Bug 288760 has been marked as a duplicate of this bug. ***
I just found out that emerging media-libs/sdl-mixer after having sourced icc's iccvars.sh fails, because that script sets INCLUDE to icc's own include path(s), and this breaks the configuration and compilation of sdl-mixer: ... configure: WARNING: *** Unable to find Ogg Vorbis library (http://www.xiph.org/) configure: WARNING: *** Unable to find FLAC library (http://flac.sourceforge.net/) configure: WARNING: *** Unable to find MAD library (http://www.underbit.com/products/mad/) ... i686-pc-linux-gnu-gcc: /opt/intel/Compiler/11.1/069/ipp/ia32/include:/opt/intel/Compiler/11.1/069/mkl/include:/opt/intel/Compiler/11.1/069/ipp/ia32/include:/opt/intel/Compiler/11.1/069/mkl/include: No such file or directory ... Had portage sanitized the environment, this wouldn't have happened. Maybe this is how the sdl-mixer .ebuild is supposed to work, but still I decided to let you guys know about this.
app-emulation/open-vm-tool-kmod fails to emerge when VERSION environment variable is set: Using 2.6.x kernel build system. make: *** No rule to make target `auto-build'. Stop.
(In reply to comment #0) > It's popped up on occasion; portage should be mangling the path so sbin ends up > in it. > Easy way to see this, sudo emerge ntp and watch if fail in enewuser since > useradd can't be found. It seems that /sbin has been added to PATH since 2001 or so: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/files/1.5/bin/ebuild.sh?hideattic=0&view=log#rev1.22 I'm closing this bug, since it doesn't seem to server any useful purpose. (In reply to comment #28) > app-emulation/open-vm-tool-kmod fails to emerge when VERSION environment > variable is set: For cases like this, the ebuild should filter the problematic environment variable itself, since there's no way for the package manager to know the difference between "desirable" and "undesirable" variables, and the definition of "desirable" and "undesirable" variables can vary from one package to another.
If the PATH was fixed in 2001, how come Brian had to create this bug 3 years later ? the issue is not fixed. If Brian had the issue 3 years after the introduction of /sbin in the PATH, is means that /sbin had been removed from the PATH somewhere between 2001 and 2004. Or that Brian met a special case where the PATH is not set properly. Why are you refusing to add VERSION to the sanitasation list ? I have asked many times to start builds in a pure clean and empty environment; this have been refused several times, and more new comes come to occur because of non-sanitised env. I have reported many variables that are known to break builds (from memory, A and/or S); why do you refuse to add VERSION to the list of purged vars ?
(In reply to comment #30) > If the PATH was fixed in 2001, how come Brian had to create this bug 3 years > later ? the issue is not fixed. If Brian had the issue 3 years after the > introduction of /sbin in the PATH, is means that /sbin had been removed from > the PATH somewhere between 2001 and 2004. Or that Brian met a special case > where the PATH is not set properly. Anyway, it seems that /sbin has been added to PATH automatically for years. > Why are you refusing to add VERSION to the sanitasation list ? I have asked > many times to start builds in a pure clean and empty environment; this have > been refused several times, and more new comes come to occur because of > non-sanitised env. As explained in comment #29, there's no way for the package manager to know the difference between "desirable" and "undesirable" variables, and the definition of "desirable" and "undesirable" variables can vary from one package to another. > I have reported many variables that are known to break builds (from memory, A > and/or S); why do you refuse to add VERSION to the list of purged vars ? The ${A} and ${S} variables are variables that have special meaning in the context of the PMS specification. The ${VERSION} variable has no special meaning.
