Package: x2goclient Version: 4.0.5.1
When an xterm is started via the x2goclient (either using the Published Applications feature, or asking for a 'Single application' of 'Terminal'), the PATH environment variable in the environment given to the user is not set as expected.
What I see from the xterm's shell:
$ echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/puppetlabs/bin:/apps/bin
What I see from an ordinary ssh login:
$ echo $PATH /apps/mpi/bin:/apps/developers/libraries/openmpi/2.0.0/1/intel-16.0.2/bin:/apps/developers/compilers/intel/16.0.2/1/default/compilers_and_libraries_2016.2.181/linux/bin/intel64:/apps/developers/compilers/intel/16.0.2/1/default/debugger_2016/gdb/intel64_mic/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/puppetlabs/bin:/apps/bin
This seems to be triggered by the fix for bug #336 (commit 4eb1fd1), which introduced the following characters into the launch commands in src/sshprocess.cpp:
export PATH=\"/usr/local/bin:/usr/bin:/bin\";
This causes a problem because the login scripts are sourced both before and after the PATH is overridden. The way that some ordinary login scripts are written behave badly in this situation - here are some examples on our CentOS 7 system:
Example 1, /etc/profile.d/qt.sh (from OS package qt3-3.3.8b-51.el7.x86_64) contains:
# Qt initialization script (sh)
# In multilib environments there is a preferred architecture, 64 bit over 32 bit in x86_64, # ppc64. When a conflict is found between two packages corresponding with different arches, # the installed file is the one from the preferred arch. This is very common for executables # in /usr/bin, for example. If the file /usr/bin/foo is found in an x86_64 package and in # an i386 package, the executable from x86_64 will be installe
if [ -z "${QTDIR}" ]; then
case uname -m in
x86_64 | ia64 | s390x | ppc64)
QT_PREFIXES="/usr/lib64/qt-3.3 /usr/lib/qt-3.3" ;;
* )
QT_PREFIXES="/usr/lib/qt-3.3 /usr/lib64/qt-3.3" ;;
esac
for QTDIR in ${QT_PREFIXES} ; do test -d "${QTDIR}" && break done unset QT_PREFIXES
if ! echo ${PATH} | /bin/grep -q $QTDIR/bin ; then PATH=$QTDIR/bin:${PATH} fi
QTINC="$QTDIR/include" QTLIB="$QTDIR/lib"
export QTDIR QTINC QTLIB PATH
fi
The first time this runs, PATH, QTDIR and the rest of the QT environment is set normally. PATH is then overridden by the x2go client. The second time this runs, $QTDIR is not a zero length string, so $QTDIR/bin is not added back to the PATH.
This explains why /usr/lib64/qt-3.3/bin does not appear in xterm's bash PATH environment variable.
Example 2, /etc/profile.d/modules.sh
We have the 'module' command installed (http://modules.sourceforge.net/) and doing something like this:
# Setup 'module' environment case "$0" in -bash|bash|*/bash) . /apps/Modules/default/init/bash ;; -ksh|ksh|*/ksh) . /apps/Modules/default/init/ksh ;; -sh|sh|*/sh) . /apps/Modules/default/init/sh ;; *) . /apps/Modules/default/init/sh ;; # default for scripts esac
Followed by /etc/profile.d/zz_modules.sh with:
# Load default module 'user' module load user
The first time this runs, PATH, the rest of the module environment and the default module are set/loaded normally, including LOADEDMODULES (which keeps track of what modules are loaded). PATH is then overridden by the x2goclient. The second time this runs, modules.sh runs normally, but the module load command in zz_modules.sh doesn't do anything as LOADEDMODULES tells it that it has already loaded 'user'. PATH remains incorrect, although other environment variables (LD_LIBRARY_PATH, etc.) are correct.
To be honest, I don't understand the logic of the bug that originally prompted the change, #336. If an attacker has access to the user's account on the remote system, there are endless possibilities for them to infiltrate the x2go client with arbitrary data.
Additionally, the fix for #336 unexpectedly limits the number of places a system administrator is permitted to install x2go.
Can someone help, please? Getting rid of overriding the server-side PATH in the client, or other solution, would allow us to offer x2go to our users, which would be really cool.
Thanks,
Mark