Red Hat Bugzilla – Bug 849452
RFE: scl sudo subcommand or equivalent
Last modified: 2016-03-21 17:16:44 EDT
Some scl-managed packages include privileged services that need the occasional sudo operation to do their job. But since sudo clears environment variables such as LD_LIBRARY_PATH or similar, which may be set by the scl /enable file, plain sudo doesn't do the right thing. It would be desirable to have an operation like % scl sudo SCL COMMAND ARGS ARGS that just wraps 'sudo scl enable SCL 'COMMAND ARGS ARGS' One motivation for doing it this way is an unfortunate aspect of the scl enable design: the command and parameters are to be squished into a single string (like sh -c), instead of being ordinary argv[] entries as per sudo, ssh, or sh. It would be convenient to have a variant with tastier syntactic sugar: % scl exec SCL COMMAND ARGS ARGS ... that expanded to basically % scl enable SCL 'COMMAND ARGS ARGS ...' (Note that, because of the sudo environment filtering, this wouldn't be sufficient for sudo wrapping. For that, another operation could do: % scl nest SCL COMMAND ARGS ARGS ... expanding to % COMMAND scl exec SCL ARGS ARGS ...
IMO the easiest solution would be to use wrapper script in case of more complicated scl invocation or in case that privilege escalation is needed. In case of privilege escalation one can even better fine-grain ACL file attributes of the script or modify SELinux context. Note that even the current scl invocation allows you to run custom scripts from /opt/rh/<collection>/ path. Currently only 'enable' scriptlet is mandatory. Your use case can be handled by creating, say 'sudo_enable' scriptlet in case that scl passes the command to be executed by a shell variable, such as $SCL_COMMAND. In that case you can do: . enable sudo $SCL_COMMAND in the sudo_enable scriptlet and the command can then be executed with privileges escalated like: scl sudo_enable SCL COMMAND ARGS ARGS ...
The sudo_enable idea wouldn't work exactly like that, because after . enable loads the various environment variables, sudo $SCL_COMMAND proceeds to cleanse the environment. I'm currently experimenting with a $SCL_ROOT/root/usr/bin/sudo wrapper script.
The sudo wrapper script idea appears to work: I'll plop it into the devtoolset-1.1 rpm in the next respin. (Is there a bugzilla component for it?)
This wrapper fails in this situation: [root@ibm-l4b-lp1]# scl_enabled && echo "ok" ok [root@ibm-l4b-lp1]# echo 5 | /usr/bin/sudo cat 5 [root@ibm-l4b-lp1]# echo 5 | sudo cat [root@ibm-l4b-lp1]#
Experimented with passing the stdin file descriptor across sudo using exec 4<&0 echo "$@ <&4" | exec /usr/bin/sudo -E -C5 scl enable devtoolset-1.1 - but sudo -C* is prohibited in default sudo configurations. Experimenting... (A native "scl sudo devtoolset-1.1 COMMAND ARGS..." seems handier every day.)
Created attachment 632150 [details] sudo wrapper, now with More Quoting (tm)
Martin, the other bit I'd test is the proper passage of the DTS environment variables. e.g., .../devtoolset-1.1/.../sudo env should show the devtoolset paths etc. set.
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. http://rhn.redhat.com/errata/RHEA-2013-0175.html
This borks sudo! See #1319936 .