Xpra: Ticket #1357: Xpra incorrectly escapes characters in run-xpra wrapperscript, causing remote sessions to fail to find server sockets

Installed Xpra 0.17.5 on Fedora 23 via dnf, and 0.17.5-r13487 on Windows 10 to use as client.

After many failed attempts at attaching, xpra never finding the display, i wrapped ~/.xpra/run-xpra on server with a strace call.

Result:

stat("/home/user.name\\@domain.net/.xpra", 0x<pointer>) = -1 ENOENT (No such file or directory)

The problem doesn't appear when running xpra locally. I'm no expert regarding xpra internals, but my take on it is that xpra in client mode tries to apply local (Windows') naming conventions and escapes the at sign, despite it being valid for the server. This results in searching for an non-existant path and failing.

A workaround is to use a global sockets-dir with a simple name (/var/run) or for lazy people like me, to symlink the incorrect homedir to the correct one... Once this is done, Xpra works as intended.

I'm thinking this defect should either be fixed, or at least documented somewhere for people that run into this problem in the future. Sadly i'm no Win32 nor xpra expert, so providing a proper patch might be beyond my capabilities.

Mon, 14 Nov 2016 15:33:55 GMT - Antoine Martin: owner changed

owner changed from Antoine Martin to firazy

The next version will also use /var/run aka XDG_RUNTIME_DIR, see #1291

We should still try to fix your problem. I'm not sure which side is doing this escaping. Do you have the full strace? I would like to see what command line arguments are used to execute xpra so I can try to fix this without needing to use a Windows system if possible. Can you please also post:

xpra_cmd showconfig

Mon, 14 Nov 2016 16:15:47 GMT - firazy: summary changed

summary changed from Windows Build incorrectly escapes characters in sockets path, causing Xpra to fail to find servers to Xpra incorrectly escapes characters in run-xpra wrapperscript, causing remote sessions to fail to find server sockets

Actually after looking a bit more thoroughly into the strace, it turns out the problem is not Windows Related indeed, and my guess was incorrect... The at-sign is already escaped wrongly in ~/.xpra/run-xpra that is generated on server-side.

Here are some excerpts from the generated run-xpra wrapper:

...
HOME="/home/user.name\@domain.net"; export HOME
...
PWD="/home/user.name\@domain.net/.xpra"; export PWD
...
cd "/home/user.name\@domain.net/.xpra"

This causes the cd to fail, but since xpra is later launched with an absolute path, it proceeds anyway. As such, even locally, running xpra with "xpra list" works, while running "~/.xpra/run-xpra list" fails.

Mon, 14 Nov 2016 16:22:11 GMT - Antoine Martin: attachment set

attachment set to shell-noquote.patch

backport of the new shell-quote function

Mon, 14 Nov 2016 16:22:29 GMT - Antoine Martin:

Does the patch above fix things?

If that doesn't fix it (it should), please post:

python -c 'import os;print(os.environ["HOME"])'

Mon, 14 Nov 2016 16:34:59 GMT - firazy:

This fixes it indeed :) Thanks!

Mon, 14 Nov 2016 16:40:04 GMT - Antoine Martin: status changed; resolution set

status changed from new to closed
resolution set to fixed

Applied in r14416, was already tracked in ticket:1259#comment:3.

Tue, 22 Nov 2016 14:30:51 GMT - Antoine Martin: milestone changed

milestone changed from 1.0 to 0.17

Sat, 23 Jan 2021 05:22:02 GMT - migration script:

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