Xpra: Ticket #707: Fallout from shellshock fix

We recently upgraded bash on our RHEL cluster following the shellshock bug announcement, and I had trouble attaching to that server.

Upgraded bash:

pprice@tigressdata:~ $ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Start xpra on server:

pprice@tigressdata:~ $ xpra --version
xpra v0.10.11
pprice@tigressdata:~ $ xpra start :10

Connect from client:

price@price-laptop:~ $ xpra attach ssh:tigressdata:10
xpra client version 0.11.1
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2014-10-06 15:06:56,021 OpenGL support not enabled: No module named gl
2014-10-06 15:06:56,053 root size is 1440x900 with 1 screen(s):
2014-10-06 15:06:56,054   'price-laptop-astro.local' 1440x900 (508x317 mm) workarea: 1440x900 at 0x0
2014-10-06 15:06:56,054     'monitor 1' 1440x900 at 0x0 (508x317 mm)
.xpra/run-xpra: line 59: syntax error near unexpected token `="\(\)\ \{\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`\}"'
.xpra/run-xpra: line 59: `\}"; export BASH_FUNC_module()'
2014-10-06 15:06:57,898 Connection lost

The problem is due to the following lines in the ~/.xpra/run-xpra script (written as part of "xpra start"):

BASH_FUNC_module()="\(\)\ \{\ \ eval\ \`/usr/bin/modulecmd\ bash\ \$\*\`\
\}"; export BASH_FUNC_module()

Following the bash upgrade, the output of the env command cannot just be fed back in to a /bin/sh script. I've had to deal with this for a different application, and we simply removed all variables starting with BASH_FUNC. We concluded that it doesn't appear that there is any truly POSIX-compliant way of exporting a function, as is done in bash.

The workaround is to manually remove the offending lines from ~/.xpra/run-xpra.

Tue, 07 Oct 2014 07:28:15 GMT - Antoine Martin: owner changed

That's odd, I don't have a RHEL machine to test on, but I've got Fedora and centos, and none of those show this problem.

I've applied the fix in r7898, does that work for you? (as per above, I am unable to verify that it works, only that the env vars that start with BASH_FUNC are no longer included)

Tue, 07 Oct 2014 13:41:45 GMT - Paul Price:

We definitely saw this on CentOS 6 with my other application, using "GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)". Is it possible that you're using a different bash version, or don't have any functions defined? Try this:

price@master:~ $ foo() { echo "foo"; }
price@master:~ $ type foo
foo is a function
foo ()
    echo "foo"
price@master:~ $ export -f foo
price@master:~ $ env | grep foo
BASH_FUNC_foo()=() {  echo "foo"

Is it easy for me to test this without root on the clusters?

Tue, 07 Oct 2014 13:45:00 GMT - Antoine Martin:

Is it easy for me to test this without root on the clusters?

Should be:

./setup.py install --home=./test
PYTHONPATH=`pwd`/test/lib64/python xpra --version

Tue, 07 Oct 2014 13:50:19 GMT - Antoine Martin: status changed; resolution set

Backport to v0.14.x in r7902. Closing, feel free to re-open if I've missed anything.

(as the TODO item says, maybe we should keep just a whitelist of the env vars we do want to preserve in here, rather than this hodgepodge blacklist.. oh well)

Wed, 08 Oct 2014 00:53:48 GMT - Paul Price:

Thanks for the fix. I haven't been able to verify it, since it's a painful build xpra on the cluster (missing dependencies; no root access/yum); sorry.

Thu, 09 Oct 2014 02:53:49 GMT - Paul Price:

The fix has propagated downstream, and it works fine, thanks!

Thu, 09 Oct 2014 03:16:49 GMT - Antoine Martin:

Out of curiosity, which downstream would that be?

Thu, 09 Oct 2014 12:05:30 GMT - Paul Price:

CentOS 6.5.

Sat, 23 Jan 2021 05:03:35 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/707