Description of problem:
the sudo "wrapper" written for #849452 is very limited, is not failsafe, and most importantly is called "sudo" and is first in search path, so takes over sudo invocations.
This is a bad idea in so many ways.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install devtoolset3
2. try to run "sudo -s" or "sudo -i"
$ sudo -s
/var/tmp/scl76ZTHd: line 8: -s: command not found
A root shell session
Others have hit this
$ rpm -qf /opt/rh/devtoolset-3/root/usr/bin/sudo
$ which sudo
The sudo wrapper is from devtoolset package not from scl-utils package, I will reassigning the bug, I hope devtoolset-meta is right component but feel free to reassign.
Certainly not solvable for DTS4.1.
Note this is basically a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1054894
Well that's not readable even for this long-time fedora contributor, but I can imagine reasons you'd have a related embargoed bz.
MITM'ing sudo is a rather bad idea. I understand the desire to have sudo load SCL envvars -- I wrestle with that myself, often needing to write wrapper scripts -- it is not important enough to mess with sudo itself; perhaps that could be achieved with a dedicated command.
(In reply to Martin Langhoff from comment #5)
> Well that's not readable even for this long-time fedora contributor, but I
> can imagine reasons you'd have a related embargoed bz.
> MITM'ing sudo is a rather bad idea. I understand the desire to have sudo
> load SCL envvars -- I wrestle with that myself, often needing to write
> wrapper scripts -- it is not important enough to mess with sudo itself;
> perhaps that could be achieved with a dedicated command.
You're right about the SCL envvars. One possibility would be to teach the sudo wrapper how to parse the sudo arguments I think -- but that seems very fragile and I'm not sure how well would that work in practice. I'm very sorry that all I can offer at this point is to recommend to use /bin/sudo if you need to use sudo options :/.
sudo_plugin(8) in the sudo-devel package might be a consideration. It looks like the API (specifically check_policy) is sufficient for implementing preservation of SCL context in a sudo plugin.
I am seeing this in devtoolset-7's sudo/ sudo -i doesn't work.
Please use /bin/sudo meanwhile.
I am seeing this while using devtoolset-6 on RH 7.5. It breaks ansible.
*** Bug 1635961 has been marked as a duplicate of this bug. ***
*** Bug 1671475 has been marked as a duplicate of this bug. ***
Look like there is no traction to fix this bug. There is a TODO in the wrapper to parse the options correctly. I have no bash expert but here is what I come up with and worked for me:
for arg in "$@"
case "$arg" in
if [ "$cmd_started" = true ]; then
elif [ "$is_option_param_next" = true ]; then
elif [[ $arg == -* ]]; then
case "$arg" in
"-g" | "-h" | "-p" | "-u" | "-U" | "-C" | "-i" | "-s")
elif [[ $arg == *=* ]]; then
if [ "$sudo_options" == "" ]; then
exec /usr/bin/sudo $sudo_options LD_LIBRARY_PATH=$LD_LIBRARY_PATH PATH=$PATH scl enable devtoolset-7 "$cmd_options"
The workaround has been to use /bin/sudo directly. The only viable solution, IMHO, would be to take a look at sudo_plugin(8) and see if that helps. But that would be for DTS 9, it's too risky to try to fix it for DTS 8.1.
(In reply to Marek Polacek from comment #14)
> The workaround has been to use /bin/sudo directly. The only viable
> solution, IMHO, would be to take a look at sudo_plugin(8) and see if that
> helps. But that would be for DTS 9, it's too risky to try to fix it for DTS
thank you for the update in this BZ. Can we proceed with evaluating the sudo_pluign and the fix? DTS 9 is okay.
What's the use case for the sudo script in DTS? I think if this feature is needed, it should be implemented properly, and as part of scl-utils.
I think the purpose was to pass PATH/LD_LIBRARY_PATH properly. This predates my involvement in DTS meta.
Maybe it is time to revisit the original scl-enable-sudo idea, so that instead of an imperfect wrapper $SCL/root/usr/bin/sudo that passes the scl PATH etc.,, we'd have a scl sudo subcommand that does the same. But this would be an RFE against the /usr/bin/scl program back under scl-utils.
WDYT, scl-utils maintainer folks?
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.