xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#1357 closed defect (fixed)

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

Reported by: firazy Owned by: firazy
Priority: major Milestone: 0.17
Component: client Version: 0.17.x
Keywords: Cc:

Description

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.

Attachments (1)

shell-noquote.patch (701 bytes) - added by Antoine Martin 3 years ago.
backport of the new shell-quote function

Download all attachments as: .zip

Change History (7)

comment:1 Changed 3 years ago by Antoine Martin

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

comment:2 Changed 3 years ago by firazy

Summary: Windows Build incorrectly escapes characters in sockets path, causing Xpra to fail to find serversXpra 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.

Last edited 3 years ago by firazy (previous) (diff)

Changed 3 years ago by Antoine Martin

Attachment: shell-noquote.patch added

backport of the new shell-quote function

comment:3 Changed 3 years ago by 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"])'

comment:4 Changed 3 years ago by firazy

This fixes it indeed :)
Thanks!

comment:5 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

comment:6 Changed 3 years ago by Antoine Martin

Milestone: 1.00.17
Note: See TracTickets for help on using tickets.