Bugzilla Bug 56407

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 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 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. ***