Bug 136027 - app-admin/sudo and hardcoded $PATH problems with gcc
|
Bug#:
136027
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: lcars@gentoo.org
|
Reported By: gentoo@davidb.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: app-admin/sudo and hardcoded $PATH problems with gcc
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-06-07 22:45 0000
|
The 'app-admin/sudo' package hardcodes the ROOT_PATH into its executable. If a
user changes GCC versions, but doesn't rebuild sudo, then commands executed via
sudo will still use the old gcc version. It would be useful to mention this in
the gcc-upgrade manual.
The rebuild of sudo is a little tricky, since if you use sudo to do it, it will
still get the old path. The easiest way to do it is:
% sudo bash -l
# emerge app-admin/sudo
With the 'bash -l' giving a login shell, which will run the /etc/profile again.
This issue is not a documentation issue -- there's a fix to this.
The gcc wrapper that is provided by gcc-config checks $PATH in the
user's environment first but will fall back and check /etc/env.d/05gcc
if $PATH does not contain a gcc-bin path. See:
/usr/portage/sys-devel/gcc-config/files/wrapper-1.4.7.c
Since sudo is always configured --with-secure-path="$ROOTPATH",
$ROOTPATH should have the gcc-bin stripped from it.
I think it's pretty clear that since the gcc-bin path is specific to
a compiler version, compiling it into sudo will necessarily result in
a broken sudo. In my opinion the correct action is to strip gcc-bin
from $PATH allowing the gcc wrapper to check the more up to date value
in /etc/env.d/.
I'm attaching a patch to sudo-1.6.8_p9-r2.ebuild which performs the
above. This patch works on my system.
Not a documentation bug; reassigning.
Is there anything happening with this bug? The current behavior of
sudo breaks gcc-wrapper functionality, making it impossible to switch
gcc profiles while using sudo. This should be fixed. The attached
patch is sufficient to create the correct behavior.
p12-r1 in cvs fixes this issue, it's ~x86 currently but assuming everything
goes well I'll file a stable request soon.
Thanks for the patch.