Others have hit this 

http://unix.stackexchange.com/questions/192809/sudo-i-returns-an-error

$ rpm -qf /opt/rh/devtoolset-3/root/usr/bin/sudo
devtoolset-3-runtime-3.1-12.el6.x86_64
$ which sudo
/opt/rh/devtoolset-3/root/usr/bin/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:

#! /bin/sh
cmd_started=false
is_option_param_next=false
for arg in "$@"
do
   case "$arg" in
    *\'*)
      arg= ;;
   esac
   if [ "$cmd_started" = true ]; then
       cmd_options="$cmd_options '$arg'"
   elif [ "$is_option_param_next" = true ]; then
       sudo_options="$sudo_options $arg"
       is_option_param_next=false
   elif [[ $arg == -* ]]; then
       sudo_options="$sudo_options $arg"
       case "$arg" in
        "-g" | "-h" | "-p" | "-u" | "-U" | "-C" | "-i" | "-s")
          is_option_param_next=true
        ;;
       esac
   elif [[ $arg == *=* ]]; then
       sudo_options="$sudo_options $arg"
   else
       cmd_options="$cmd_options '$arg'"
       cmd_started=true
   fi
done
if [ "$sudo_options" == "" ]; then
    sudo_options="-E"
fi
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
> 8.1.

Hello Marek,

thank you for the update in this BZ. Can we proceed with evaluating the sudo_pluign and the fix? DTS 9 is okay.

-Roman

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.

https://access.redhat.com/errata/RHEA-2019:4132