Bug 1319936
Summary: | sudo is broken after installing devtoolset | ||
---|---|---|---|
Product: | Red Hat Developer Toolset | Reporter: | Martin Langhoff <martin> |
Component: | devtoolset-meta | Assignee: | Frank Ch. Eigler <fche> |
Status: | CLOSED ERRATA | QA Contact: | Martin Cermak <mcermak> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | DTS 3.1 RHEL 6 | CC: | amike, boringuy, fche, fperalta, fweimer, gsgatlin, jakub, mbenitez, mcermak, michael.alberghini, mnewsome, mpolacek, ohudlick, packaging-team-maint, pasteur, rbgarga, rbobek, rhel |
Target Milestone: | alpha | ||
Target Release: | 5.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | devtoolset-9-9.0-3.el7 | Doc Type: | Bug Fix |
Doc Text: |
Cause:
The /opt/redhat/devtoolset*/root/usr/bin/sudo wrapper script did not correctly parse all sudo options.
Consequence:
Some sudo modes (e.g., sudo -i) could not be executed.
Fix:
More sudo options are correctly parsed.
Result:
The sudo wrapper works more like the normal /usr/bin/sudo.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2019-12-10 07:49:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Martin Langhoff
2016-03-21 21:14:37 UTC
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 |