Xpra: Ticket #276: clipboard direction restrictions: client to server only, server to client only

It may be useful to provide a way of doing that.

VirtualBox does this for example.

Maybe:

--clipboard=[copy|paste|both|off|disabled]

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').



Thu, 28 Feb 2013 16:18:39 GMT - Antoine Martin: status, description changed


Tue, 15 Oct 2013 12:43:04 GMT - Antoine Martin: description changed


Sun, 24 Apr 2016 12:32:06 GMT - L29Ah:

Actually it would be awesome to make it switchable with xpra control.


Sun, 24 Apr 2016 12:37:54 GMT - L29Ah:

Er, no, that wouldn't be very secure. Via a key-shortcut then.


Sun, 24 Apr 2016 17:42:56 GMT - Antoine Martin:

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.


Sun, 24 Apr 2016 18:18:02 GMT - L29Ah:

Replying to 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.


Mon, 30 May 2016 06:07:12 GMT - Antoine Martin: attachment set

mostly complete patch


Mon, 30 May 2016 09:16:44 GMT - Antoine Martin: owner, status changed

Implemented in r12709: use clipboard-direction=to-server|to-client|both|disabled. Can also be toggled from the systray, as of r12711 via xpra control or the server dbus interface (#904).

@L29Ah: does this work for you?


Tue, 31 May 2016 22:09:45 GMT - L29Ah:

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.

Wed, 01 Jun 2016 02:34:46 GMT - Antoine Martin:

@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: http://xpra.org/beta.


Thu, 02 Jun 2016 11:45:57 GMT - L29Ah:

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/tty0

Fri, 03 Jun 2016 01:41:25 GMT - Antoine Martin:

Those 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.


Tue, 27 Sep 2016 09:23:47 GMT - Antoine Martin: owner, milestone changed

@afarr: you may be interested in this feature (ignore comment:7 onwards which have nothing to do with this)


Sat, 01 Oct 2016 00:57:04 GMT - alas: owner changed

Was expecting to just do a quick test, 1.0 r13937 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.

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'

Using the same --clipboard-direction=to-server as 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-client seems to work as expected, though it also can't be changed on the fly.

Ran a test with -d clipboard running both server and client, with --clipboard-direction=to-server... and collected logs which I'll attach. Quick script.


Sat, 01 Oct 2016 00:58:17 GMT - alas: attachment set

server logs


Sat, 01 Oct 2016 00:59:57 GMT - alas: attachment set

client side -d clipboard logs


Sat, 01 Oct 2016 02:28:38 GMT - Antoine Martin: status changed


Wed, 05 Oct 2016 17:30:31 GMT - Antoine Martin: owner, status changed

Congratulations on hitting issues I had missed, right on your first attempt!

Lots of fixes:

This should also improve compatibility with older clients and server (though that's not guaranteed to work quite as well as before when mixing with older versions and using this flag). We now also have automated unit tests for the clipboard, including one that tries to mimic the osx clipboard behaviour on Linux. (turning on "want-targets" and "greedy" options). And I have been testing this feature by hand on multiple platforms.


That said... I know you're kinda gifted for finding issues, so I'm not promising that we're done here..

If you still find problems with this feature, please try to reduce the scope of the bug hunt by running tests as similar as you can make them to the unit tests:

We can worry about the use of the server-side flag, runtime changes via the dbus and control channels, or using the system tray UI to change the settings later. (or any combination of those - which could take forever..)

If you still find any problems with this or with the simple test cases above, please include:


Fri, 09 Dec 2016 22:49:03 GMT - alas: owner, priority changed

Tested some more, using just client-side flags, with OSX 1.0 r14467 and windows 1.0 r14492 client, against 1.0 r14502 fedora 23 server.

There are some odd messages when I try to copy the entire contents, locally, of a 75KB file in order to paste server side:

C:\Program Files (x86)\Xpra\library.zip\xpra\clipboard\clipboard_base.py:717: GtkWarning: gdkselection-win32.c:423: OpenClipboard failed: Access is denied.
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdk_property_delete: assertion `window != NULL' failed
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: inner_clipboard_window_procedure: assertion `success' failed

And the additional messages upon disconnection afterward of:

2016-12-09 11:05:25,966 received console event CTRL_C
2016-12-09 11:05:25,974 sound output stopping
sys.excepthook is missing
lost sys.stderr

The clipboard contents copied and pasted as hoped though.

Unfortunately, with the --clipboard-direction=both, after copying anything server side, further copying locally fails to sync to the server-side clipboard (and with -d clipboard running on the server, there is no indication of anything happening when doing further copying locally... and likewise the contents of the gtk_view_clipboard tool don't update with new contents after a local copy).

Even more unfortunately, it looks like that same behavior is seen when using the default value of 'both'... so if I don't use any clipboard-direction flag with the OSX client, once I copy something on the server, I can no longer sync local copying with the server clipboard(s).

That's a problem.

Easy repro.

Whatever the contents were of that first copy server side is what will paste.

I'll attach some short logs from both server and client side... following the above steps with a gedit window prepared in advance with contents of "server-side-content", after the copying of which I copied "client-side-content" from a textedit window, then tried to paste that back into the server-side gedit window (and got a second copy of "server-side-content".

Since I didn't even have to bother with the client side flags to trigger this, I'm going to raise the Priority.


Fri, 09 Dec 2016 22:58:23 GMT - alas: attachment set

server -d clipboard logs with bonus client remote logging logs for same, with same


Thu, 29 Dec 2016 11:39:31 GMT - Antoine Martin: owner changed

r14641 fixes the spurious invalid value for clipboard-direction warning. "disabled" is a valid option.

With r14638 + r14642, we're now back to the same code as r13977... Which means we should not be clearing the server side value when "disabled" is used and OSX clients should get the new value if the server side value is changed. I hope this doesn't break some other use case!


Thu, 29 Dec 2016 11:47:56 GMT - Antoine Martin: priority changed

(raising as I would like to include this in 1.0.1)


Fri, 30 Dec 2016 02:29:18 GMT - rektide: cc set


Tue, 03 Jan 2017 16:34:17 GMT - Antoine Martin: owner, status changed

Taking this back: I believe this causes a clipboard loop on Linux. It even causes the whole client to deadlock following the message clipboard toggled to off by the server, reason given: more than 20 clipboard requests per second''


Thu, 05 Jan 2017 17:13:35 GMT - Antoine Martin:

Fix in r14704 for the deadlocks, already backported. (useful fix for an existing deadlock pattern which just occured more readily with the attempt at a fix for the osx clipboard)

But the OSX clipboard is still not syncing properly (as per comment:16).


Sat, 07 Jan 2017 09:43:11 GMT - Antoine Martin: owner, status changed

r14720 fixes a bug where syncing would stop with osx clients, r14722 adapts it to v1.0.x to prevent sync loops.

I have published 1.0.1 with this change... so I hope I haven't missed anything critical.

I think #1400 will be useful, especially if osx clients sync with PRIMARY.


Wed, 11 Jan 2017 18:55:39 GMT - alas:

Did some quick tests with 1.0.1 r14723 osx client (from dists) against a 1.0.1 r14570 fedora 23 server.

As mentioned above, looks like OSX clipboard is still not sync'ing correctly, but otherwise behavior seems the same - though I'm not sure how to induce the sync loops that you mentioned (I think I know which ones you mean, but I've never been able to reliably repro them).

In any case, the work in r14722 doesn't seem to have caused any regressions.

I'll hand this back to you pending inspiration on sync'ing the clipboards the rest of the way.


Thu, 12 Jan 2017 05:46:41 GMT - Antoine Martin:

r14765 applies the fix to the 1.0.x branch, it's been in trunk long enough and I haven't seen any negative side effects. But maybe you will?

New OSX beta 1.0.2 build uploaded.


Mon, 16 Jan 2017 23:53:50 GMT - J. Max Mena:

Using a Fedora 25 r14799 1.X server with a Windows 8.1 r14780 1.X client I am getting periodic clipboard crashes. Just copying and pasting is enough to cause the whole server to stop responding.

On the client side I get this traceback most of the time (1/5 times I didn't get it):

C:\Program Files (x86)\Xpra\library.zip\xpra\clipboard\clipboard_base.py:600: GtkWarning: gdk_property_change: assertion
 `type != GDK_TARGET_STRING' failed
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdkgc-win32.c:830: SaveDC failed: T
he operation completed successfully.
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdkgc-win32.c:970: RestoreDC failed
: The operation completed successfully.
pnc=: T2017-01-16 15:35:07,047 sound output stopping

And one time on the server I got this print:

Our peer requested the contents of the clipboard, but *I* thought *they* had it... weird.

Will retry with -d clipboard.

edit: After mentioning this to afarr - he suggested commenting here.


Tue, 17 Jan 2017 00:29:30 GMT - J. Max Mena:

Hmmmm looks to be easily triggered by using start-desktop with a --start-child=startlxde with LXDE installed - LXDE seems to be spamming the clipboard with small copies to the point that the clipboard breaks.

I see this being spammed in the server side logs:

2017-01-16 19:10:54,507 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,721 clipboard: CLIPBOARD owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: CLIPBOARD owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False

Tue, 17 Jan 2017 16:04:29 GMT - Antoine Martin: owner changed

Let's ignore the lxde problem from comment:26 for now, lxde starts a clipboard manager by default - which is bound to cause problems.

Is the problem you are reporting in comment:25 a regression in 1.0.1 from 1.0? What do I need to do to reproduce it? I can't get it to misbehave that badly. Do you have logs?


Wed, 18 Jan 2017 18:59:44 GMT - J. Max Mena: owner changed

After discussing this with Antoine, the issue I was mentioning was specific to LXDE and the start-desktop feature. As such I'm gonna hand it back to afarr, but I'll try to take a look at the clipboard a bit more today just to make double sure that we haven't introduced any new issues.


Thu, 16 Feb 2017 04:35:53 GMT - Antoine Martin:

Important bug fix in r15030 (r15031 for v1.0.x branch), maybe this also helps with the "start-desktop" mode.


Tue, 18 Apr 2017 00:53:08 GMT - alas:

Well, I made some time, but found that some shared systems needed some tinkering to set back up. Will test this soon... but failed this time.


Tue, 25 Apr 2017 18:23:55 GMT - J. Max Mena: owner changed

Using a 1.X r15617 Client and Server - both machines running Fedora 25:

That being said, starting a server with --clipboard-direction=to-server seems to have no effect, until I try to change the direction using the tray.

I'll get some logs in a second.


Tue, 25 Apr 2017 18:26:11 GMT - J. Max Mena: owner changed

Okay, of course, when trying to get the logs and paste them into a file the limiting directions start working.

I'll take this until I figure out what went wrong. I probably just got unlucky.


Tue, 25 Apr 2017 21:05:47 GMT - J. Max Mena: owner changed

Okay I figured it out. Only to-server was the problem - I accidentally hit up one too many times and started with to-client.

edit: forgot to change tense.

However, when trying to get logs using the following steps:

It was broken both directions. When doing the to-server part, I could copy both ways from the get-go. When doing the to-client, the clipboard didn't work at all and updated the local and remote ones separately.

Using the --clipboard-direction flag causes some serious clipboard instability. Sometimes it works fine (usually with to-server), sometimes it breaks horribly.

Either way, I'll post the logs I got.


Tue, 25 Apr 2017 21:07:39 GMT - J. Max Mena: attachment set

client side logs with --clipboard-direction=to-client


Tue, 25 Apr 2017 21:07:55 GMT - J. Max Mena: attachment set

client side logs with --clipboard-direction=to-server


Tue, 25 Apr 2017 21:08:13 GMT - J. Max Mena: attachment set

server side logs with --clipboard-direction=to-client


Tue, 25 Apr 2017 21:08:28 GMT - J. Max Mena: attachment set

server side logs with --clipboard-direction=to-server


Wed, 26 Apr 2017 18:13:28 GMT - Antoine Martin: owner changed

Okay I figured it out. Only to-server was the problem - I accidentally hit up one too many times and started with to-client.

I guess this means I can safely ignore comment:31 and comment:32?

It was broken both directions. When doing the to-server part, I could copy both ways from the get-go. When doing the to-client, the clipboard didn't work at all and updated the local and remote ones separately.

I am unable to reproduce any of those problems, I've tried with both the 1.0.x branch and trunk. Repeatedly.

Please document the exact command lines that you've used. It is much easier to reproduce reliably using "xclip" commands rather than relying on descriptions of the steps using a heavyweight application like firefox. (which is also known for having its own clipboard quirks)

Using the --clipboard-direction flag causes some serious clipboard instability. Sometimes it works fine (usually with to-server), sometimes it breaks horribly.

Please define "instability" and "breaks horribly". Did it eat some kittens?


Here's an example of my test results with "to-client":

xpra start -d clipboard :100
xpra attach -d clipboard :100 --clipboard-direction=to-client
echo "set client clipboard to a known value" | xclip -i -selection CLIPBOARD
#verify that there is no data in the server clipboard:
DISPLAY=:100 xclip -o -selection CLIPBOARD
Error: target STRING not available
#set a value:
echo "server value" | DISPLAY=":100" xclip -i -selection CLIPBOARD
#verify it is set on the server:
DISPLAY=:100 xclip -o -selection CLIPBOARD
#and now also on the client:
xclip -o -selection CLIPBOARD
#change the client value:
echo "new client value" | xclip -i -selection CLIPBOARD
#verify that the server value has not changed:
DISPLAY=:100 xclip -o -selection CLIPBOARD

If you get unexpected results following a scenario like this one, grab the log samples of just when the problem occurs. If you don't, then we'll know that the problem requires a more specific setup / command-line / options / client application etc. Then you can tweak until the problem occurs.


Fri, 28 Apr 2017 23:19:23 GMT - J. Max Mena:

I guess this means I can safely ignore comment:31 and comment:32?


Yes.


Please document the exact command lines that you've used.


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 with xpra attach tcp:ip -d clipboard.


Please define "instability" and "breaks horribly". Did it eat some kittens?


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.


Sat, 29 Apr 2017 19:27:45 GMT - dragon788:

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.


Thu, 04 May 2017 20:11:28 GMT - J. Max Mena:

@dragon788 - thanks for that, that makes a lot of sense.

@antoine:

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-server as 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-client works fine - it didn't break the clipboard at all, even after several sessions.


Fri, 05 May 2017 06:38:18 GMT - Antoine Martin:

So the only problem is with to-server set 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?


Tue, 09 May 2017 16:34:09 GMT - J. Max Mena:

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>&1 and connected. On this connect, clipboard did not work in either direction - tested using gedit on my local machine and xfce4-terminal on the remote machine.

I'll try getting a log sample of it working as expected.


Tue, 09 May 2017 16:35:06 GMT - J. Max Mena: attachment set

-d clipboard logs of broken clipboard sync - serverside


Tue, 09 May 2017 16:35:20 GMT - J. Max Mena: attachment set

-d clipboard logs of broken clipboard sync - client side


Tue, 09 May 2017 16:38:00 GMT - J. Max Mena: attachment set

Serverside logs of working clipboard restriction


Tue, 09 May 2017 16:38:50 GMT - J. Max Mena: attachment set

client side logs of working clipboard restriction


Wed, 10 May 2017 14:06:33 GMT - Antoine Martin:

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 CLIPBOARD

At 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.


Fri, 12 May 2017 16:42:30 GMT - J. Max Mena:

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.


Sat, 13 May 2017 03:54:03 GMT - Antoine Martin:

Thanks, fix backported in r15820.


Tue, 16 May 2017 16:53:54 GMT - J. Max Mena: status changed; resolution set

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.


Sat, 23 Jan 2021 04:50:19 GMT - migration script:

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