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
_______________________________________________
x2go-dev mailing list
[email protected]
http://lists.x2go.org/listinfo/x2go-dev
