X2Go Bug report logs - #1100
xterm's shell started from x2goclient has wrong PATH

Full log

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

Received: (at submit) by bugs.x2go.org; 11 Oct 2016 15:03:35 +0000
From m.c.dixon@leeds.ac.uk  Tue Oct 11 17:03:29 2016
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,SPF_HELO_PASS
	autolearn=ham version=3.3.2
Received: from localhost (localhost [127.0.0.1])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 059BF3BCE1
	for <submit@bugs.x2go.org>; Tue, 11 Oct 2016 17:03:29 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de
Received: from ymir.das-netzwerkteam.de ([127.0.0.1])
	by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id EQVmTkyu3z5p for <submit@bugs.x2go.org>;
	Tue, 11 Oct 2016 17:03:22 +0200 (CEST)
X-Greylist: delayed 2773 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Tue, 11 Oct 2016 17:03:22 CEST
Received: from mhost02h.leeds.ac.uk (mhost02h.leeds.ac.uk [129.11.77.151])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 47FC03BCDA
	for <submit@bugs.x2go.org>; Tue, 11 Oct 2016 17:03:22 +0200 (CEST)
Received: from mhost04c.leeds.ac.uk (mhost04c-smtps.leeds.ac.uk [129.11.76.129])
	by mhost02h.leeds.ac.uk (8.14.4/8.14.4) with ESMTP id u9BEH8nQ023305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
	for <submit@bugs.x2go.org>; Tue, 11 Oct 2016 15:17:08 +0100
Received: from isssun11.leeds.ac.uk (isssun11.leeds.ac.uk [129.11.152.8])
	(authenticated bits=0)
	by mhost04c.leeds.ac.uk (8.14.9/8.14.9) with ESMTP id u9BEH78b001491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
	for <submit@bugs.x2go.org>; Tue, 11 Oct 2016 15:17:08 +0100 (BST)
Date: Tue, 11 Oct 2016 15:17:07 +0100 (BST)
From: Mark Dixon <m.c.dixon@leeds.ac.uk>
X-X-Sender: mark@bodgerer
To: submit@bugs.x2go.org
Subject: xterm's shell started from x2goclient has wrong PATH
Message-ID: <alpine.LRH.2.20.1610111219530.6492@bodgerer>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-UOL-RateLimit: userRateLimit[a:m.c.dixon@leeds.ac.uk,c:4.794119074013803,l:500.0]

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

Send a report that this bug log contains spam.