[X2Go-Dev] Bug#1100: xterm's shell started from x2goclient has wrong PATH

[Mark Dixon]

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