#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)
Change History (8)
comment:1 Changed 4 years ago by
Owner: | changed from Antoine Martin to firazy |
---|
comment:2 Changed 4 years ago by
Summary: | Windows Build incorrectly escapes characters in sockets path, causing Xpra to fail to find servers → 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.
Changed 4 years ago by
Attachment: | shell-noquote.patch added |
---|
backport of the new shell-quote function
comment:3 Changed 4 years ago by
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:5 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Applied in r14416, was already tracked in ticket:1259#comment:3.
comment:6 Changed 4 years ago by
Milestone: | 1.0 → 0.17 |
---|
comment:7 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1357
The next version will also use
/var/run
akaXDG_RUNTIME_DIR
, see #1291We 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: