Repository navigation
clipboard direction restrictions: client to server only, server to client only #276
Description
Activity
2016-04-24 13:32:06: L29Ah commented
Actually it would be awesome to make it switchable with
xpra control.2016-04-24 13:37:55: L29Ah commented
Er, no, that wouldn't be very secure. Via a
key-shortcutthen.How is a key shortcut more secure than the control channel?
The control channel can be made to require authentication, key presses are trivial to inject into any local X11 application.2016-04-24 19:18:03: L29Ah commented
Replying to [comment:5 antoine]:
How is a key shortcut more secure than the control channel?
The control channel can be made to require authentication, key presses are trivial to inject into any local X11 application.Never mind, they are both needed and security depends on the use case. In my case the server runs in the unsafe environment, so its actions cannot be relied upon; it sure can be otherwise, although it looks strange from my point of view.
2016-05-30 07:07:13: antoine uploaded file
clipboard-directions.patch(38.1 KiB)mostly complete patch
2016-05-31 23:09:45: L29Ah commented
Tried to build trunk:
clang -O2 -pipe -O2 -pipe -march=native -fno-strict-aliasing -fPIC -I/usr/include/python2.7 -c xpra/x11/bindings/wait_for_x_server.c -o /var/tmp/paludis/x11-wm-xpra-9999/work/xpra-9999-python2_7/temp.linux-x86_64-2.7/xpra/x11/bindings/wait_for_x_server.o -Wall -Werror -Wno-unneeded-internal-declaration -Wno-unknown-attributes -Wno-unused-function -Wno-sometimes-uninitialized In file included from xpra/x11/bindings/wait_for_x_server.c:26: In file included from /usr/include/python2.7/Python.h:126: /usr/include/python2.7/modsupport.h:27:65: error: 'format' attribute argument not supported: _PyArg_ParseTuple_SizeT [-Werror,-Wignored-attributes] PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); ^ /usr/include/python2.7/pyport.h:908:57: note: expanded from macro 'Py_FORMAT_PARSETUPLE' #define Py_FORMAT_PARSETUPLE(func,p1,p2) __attribute__((format(func,p1,p2))) ^ 1 error generated.@l29ah: this looks like a toolchain issue, please file a separate ticket for that.
Alternatively, there should be recent beta builds with this change here: https://xpra.org/beta2016-06-02 12:45:58: L29Ah commented
Stripped away -Werror, got this:
(EE) Fatal server error: (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)Even though /dev/tty0 is there:
crw--w---- 1 root tty 4, 0 май 19 19:59 /dev/tty0Those compilation errors are unrelated to this ticket, please use a separate ticket and include the full error.
Looks like your xvfb option is not configured properly. If you are on Ubuntu, you need to build with--without-Xdummy.2016-10-01 01:57:04: afarr commented
Was expecting to just do a quick test, 1.0 13937 osx client, 1.0 r13912 fedora 23 server... but I seem to be running into issues when trying to use the control channel to set clipboard direction.
- With either
xpra control :13 clipboard-direction to-serverorxpra control :13 clipboard-direction to-client, I get an error code 127 in the ssh shell in which I try to send the command:
server returned error code 127 error processing control command: 'XpraServer' object has no attribute 'client'Interestingly, I get the same message about no attribute 'client' whether I'm trying to set "to-client" or "to-server".
The server logs are more verbose with the problem:
2016-09-30 16:45:02,914 error processing control command 'clipboard-direction' Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 1037, in process_control_command v = command.run(*args[1:]) File "/usr/lib64/python2.7/site-packages/xpra/server/control_command.py", line 67, in run return super(ArgsControlCommand, self).run(*args) File "/usr/lib64/python2.7/site-packages/xpra/server/control_command.py", line 32, in run return self.do_run(*args) File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 1699, in control_command_clipboard_direction self.client.clipboard_helper.set_direction(can_send, can_receive) AttributeError: 'XpraServer' object has no attribute 'client'-
Likewise, when I try to use d-feet to run the
setClipboardDirectiondbus command... when I enterto-serverI get a"name 'to' is not defined"message and, of course, enteringserverproduces a"name 'server' is not defined"message. -
With a
--clipboard-direction=to-serverset client-side upon connection, I notice no effect, and using the "application menu -> xpra -> clipboard -> clipboard/server to client only" tray-like option of the osx client to try to set the value on the fly (clipboard seems to be working in all directions despite use of the client-side flag) seems to produce absolutely no change.
Using the same
--clipboard-direction=to-serveras a server flag does produce a warning for the client about the clipboard direction limits, but rather than just limiting clipboard functionality to copies client-side syncing and being pastable to server session... it looks like the clipboard (clipboard clipboard, if you will) begins failing to sync at all in either direction after any contents are copied on the client-side; with selections copied server-side pasting server side, while selections pasted client-side are pasting client-side... and never the twain do meet (got logs of this behavior, with outline of what steps I logged below).--clipboard-direction=to-clientseems to work as expected, though it also can't be changed on the fly.Ran a test with
-d clipboardrunning both server and client, with--clipboard-direction=to-server... and collected logs which I'll attach. Quick script.- I copied something client-side, and pasted it successfully "to-server".
- I then copied something server-side and failed to paste it "to-client" (as expected... paste back to-client pasted the contents of the client-side clipboard, un-sync'd by the paste action server-side... i.e. exactly what I'd pasted "to-server" in that first copy/paste) .
- I then copied something else client-side, which failed to paste "to-server" (at this point, the contents that were pasted were exactly what had just been copied server-side, and then failed to paste "to-client" in the previous (second star) step... indicating that, after having blocked to sync of the clipboard clipboard server-side upon the copying/updating of new contents client-side (second star), further copying server-side likewise begins failing to sync contents to client-side clipboard (at which point, neither side is sync'ing, and the behavior has gone from "to-server" to "disabled" - third star).
- With either
2016-10-01 01:58:17: afarr uploaded file
xpra-ticket276-to-server-d-clipboard-server-logs.txt(71.3 KiB)server logs
2016-10-01 01:59:57: afarr uploaded file
xpra-ticket276-to-server-on-server_client-log.txt(37.2 KiB)client side -d clipboard logs
- dbus / xpra control "clipboard-direction": fixed and improved in r13942 (will be added to unit tests I am writing)
- d-feet requires string arguments to be quoted, ie:
"to-server" - the rest is likely to be caused by a clipboard-challenged OS (win32 and even more so for osx) - will take a look
26 remaining items
2017-04-29 00:19:23: maxmylyn commented
I guess this means I can safely ignore comment:31 and comment:32?
[[br]]Yes.
[[br]]
Please document the exact command lines that you've used.
[[br]]
For server start I used
xpra start :13 --bind-tcp=0.0.0.0: --start-child=xterm --start-child=firefox --clipboard-direction=to-client/to-server, and I connected withxpra attach tcp:ip -d clipboard.[[br]]
Please define "instability" and "breaks horribly". Did it eat some kittens?
[[br]]
My bad, I forgot to explain. When I said instability and breaks, I meant that sometimes it works fine, and other times it breaks completely. By breaks horribly I mean that it'll either not respect direction, or it'll break clipboard sync entirely, and I'll end up with the server and the client with separate clipboards entirely.
Moving along, I still don't follow the xclip commands, despite having stared at them for a few hours today. I'll follow up with them on Tuesday.
2017-04-29 20:27:45: dragon788 commented
maxmylyn, maybe this will help break down the xclip for you? https://explainshell.com/explain?cmd=DISPLAY%3D%3A100+xclip+-o+-selection+CLIPBOARD
Basically the -i/-o is "in" or "out", aka stdin (to xclip) or stdout (from xclip). By starting xpra with the clipboard "bound" to display :100, when you call xclip with DISPLAY=:100 (there is also a --display option iirc) it targets the xpra session rather than local. When it was called without DISPLAY=:100 it is then showing your current local client clipboard to show that it was a one way sync.
2017-05-04 21:11:28: maxmylyn commented
@dragon788 - thanks for that, that makes a lot of sense.
Okay I followed the steps you mentioned in comment:34 and it's working fine. And, using the
--clipboard-direction=from the client side seems to also be working just fine with r15794.Keeping in mind using a more lightweight application, I decided to start my server using
xpra start :13 --bind-tcp=0.0.0.0: --start-child=xfce4-terminal --clipboard-direction= -d clipboard. Using--clipboard-direction=from the server side is where I seem to be running into some trouble. Setting it to--clipboard-direction=to-serveras a part of the server start command broke my clipboard sync entirely about 40-50% of the time (tested several times), in which case the clipboard didn't sync at all and I ended up with two clipboards (remote and local). However, using--clipboard-sync=to-clientworks fine - it didn't break the clipboard at all, even after several sessions.2017-05-05 07:38:18: antoine commented
So the only problem is with
to-serverset on the server?
When you say it breaks 40% or 50% of the time, is this initially or after some events?
Could this be timing related? Does the type of client matter?
Do you have minimal logs comparing the working and non-working case?2017-05-09 17:34:10: maxmylyn commented
Amazingly I got it to break sync on the first try. I started the server with
xpra start :13 --start-child=xfce4-terminal --bind-tcp=0.0.0.0: --clipboard-direction=to-server --no-daemon -d clipboard > /home/max/276brokenclipboard.txt 2>&1and connected. On this connect, clipboard did not work in either direction - tested usinggediton my local machine andxfce4-terminalon the remote machine.I'll try getting a log sample of it working as expected.
2017-05-09 17:35:06: maxmylyn uploaded file
276brokenclipboard.txt(16.5 KiB)-d clipboard logs of broken clipboard sync - serverside
2017-05-09 17:35:20: maxmylyn uploaded file
276clientbrokenclipboard.txt(4.8 KiB)-d clipboard logs of broken clipboard sync - client side
2017-05-09 17:38:00: maxmylyn uploaded file
276workingclipboard.txt(22.9 KiB)Serverside logs of working clipboard restriction
2017-05-09 17:38:51: maxmylyn uploaded file
276clientworkingclipboard.txt(10.2 KiB)client side logs of working clipboard restriction
2017-05-10 15:06:33: antoine commented
Much more reliable steps to reproduce the problem:
#set clipboard value on client: echo foo | xclip -i -selection CLIPBOARD #verify the server has synced it: DISPLAY=:100 xclip -o -selection CLIPBOARD #change the value on the server: echo bar | DISPLAY=:100 xclip -i -selection CLIPBOARD #verify that the client has not synced it: xclip -o -selection CLIPBOARD #set a new clipboard value on client: echo foo-again | xclip -i -selection CLIPBOARD #show the server clipboard value: DISPLAY=:100 xclip -o -selection CLIPBOARDAt this point the server still has the old "bar" value, because it hasn't sent the token to the client when the value changed to "bar", and so the client can't sent the token back when its value changed to "foo-again".
r15799 fixes this. This is scheduled for the next 1.0 update, please check that this fixes your problem and that it doesn't cause any regressions.
2017-05-12 17:42:30: maxmylyn commented
A quick sanity test has concluded that it fixed the specific issue I found. I'll take a few minutes now and make sure no regressions came up. I'll likely close this in an hour or so.
2017-05-13 04:54:03: antoine commented
Thanks, fix backported in 15820.
2017-05-16 17:53:54: maxmylyn commented
Alright I took a few minutes out of this morning to double check - and r15799 fixes the specific issue I found. As far as I can tell it doesn't break any other clipboard functions(double checked both direction limitations, disabled copmletely, along with no restrictions), so I'm going to finally close this ticket at long last.
Cheers.
It may be useful to provide a way of doing that.
VirtualBoxdoes this for example.Maybe:
So each end can limit what it will support.
And a toggle at runtime via the tray menu (as long as it is not '
disabled').