xpra icon
Bug tracker and wiki

Opened 4 years ago

Last modified 6 weeks ago

#276 new enhancement

clipboard direction restrictions: client to server only, server to client only

Reported by: Antoine Martin Owned by: alas
Priority: blocker Milestone: 1.0
Component: core Version:
Keywords: Cc: rektide@…

Description (last modified by Antoine Martin)

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

Attachments (4)

clipboard-directions.patch (38.1 KB) - added by Antoine Martin 10 months ago.
mostly complete patch
xpra-ticket276-to-server-d-clipboard-server-logs.txt (71.3 KB) - added by alas 6 months ago.
server logs
xpra-ticket276-to-server-on-server_client-log.txt (37.2 KB) - added by alas 6 months ago.
client side -d clipboard logs
ticket276_server-logs-d-clipboard_with-client-remote-logs-included.txt (34.7 KB) - added by alas 4 months ago.
server -d clipboard logs with bonus client remote logging logs for same, with same

Download all attachments as: .zip

Change History (33)

comment:1 Changed 4 years ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 3 years ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 11 months ago by L29Ah

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

comment:4 Changed 11 months ago by L29Ah

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

comment:5 Changed 11 months ago by 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.

comment:6 in reply to:  5 Changed 11 months ago by 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.

Changed 10 months ago by Antoine Martin

Attachment: clipboard-directions.patch added

mostly complete patch

comment:7 Changed 10 months ago by Antoine Martin

Owner: changed from Antoine Martin to L29Ah
Status: assignednew

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?

comment:8 in reply to:  7 Changed 10 months ago by 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.
Last edited 10 months ago by Antoine Martin (previous) (diff)

comment:9 Changed 10 months ago by 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.

comment:10 Changed 10 months ago by 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
Last edited 10 months ago by Antoine Martin (previous) (diff)

comment:11 Changed 10 months ago by 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.

comment:12 Changed 6 months ago by Antoine Martin

Milestone: future1.0
Owner: changed from L29Ah to alas

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

comment:13 Changed 6 months ago by alas

Owner: changed from alas to Antoine Martin

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.

  • With either xpra control :13 clipboard-direction to-server or xpra 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 setClipboardDirection dbus command... when I enter to-server I get a "name 'to' is not defined" message and, of course, entering server produces a "name 'server' is not defined" message.
  • With a --clipboard-direction=to-server set 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-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.

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

Changed 6 months ago by alas

server logs

Changed 6 months ago by alas

client side -d clipboard logs

comment:14 Changed 6 months ago by Antoine Martin

Status: newassigned
  • 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

comment:15 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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

Lots of fixes:

  • OSX clients could still receive server side changes in "to-server" mode, fixed in r13976. Note: when using this clipboard-direction option client-side, the server may still send the clipboard data down the wire to the client, the client will just ignore the data. (will follow up in #1329 for a better fix to avoid even sending it)
  • OSX clients in "to-client" mode could clear the server-side buffer by copying something into the clipboard (the data would not get copied across however), fixed in r13977
  • the state could get wedged when switching the direction of copying and a direction restriction is in place, fixed in r13989 (r13990 for osx), probably explains the "no longer syncs" issue
  • OSX clipboard code is "greedy" so we have to send data with the tokens, fixed in r14007

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:

  • using the flag with the client only
  • copying in and out with xclip to verify (notepad on win32 / textedit on osx)
  • copying in one direction twice then the other way, the back to the original direction

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:

  • the exact commands you used, including xclip and steps (as simple as can be)
  • the value that was copied across (and make it easy to spot, ie: COPIED_FROM_OSX_CLIENT)
  • logs - as small as can be
  • whether the bug occurs on other platforms or not (in particular Linux, which is so much easier to test and debug)

comment:16 Changed 4 months ago by alas

Owner: changed from alas to Antoine Martin
Priority: minormajor

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.

  • With the windows client, all the options are working as hoped, except for the minor issue that with --clipboard-direction=disabled - if something is copied locally it clears the clipboard on the server side. A very minor issue.

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.

  • With the OSX client, I see the same clearing of the server-side clipboard contents upon copying anything locally with --clipboard-direction=disabled, and I also see an odd message upon starting:
    Warning: invalid value for clipboard-direction: 'disabled'
     specify 'to-server', 'to-client' or 'both'
    

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.

  • Connect OSX client.
  • Using a browser, or even just gedit, copy something on the server-side.
  • Copy something else client side & try to paste server side.

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.

Changed 4 months ago by alas

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

comment:17 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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!

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:18 Changed 3 months ago by Antoine Martin

Priority: majorblocker

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

comment:19 Changed 3 months ago by rektide

Cc: rektide@… added

comment:20 Changed 3 months ago by Antoine Martin

Owner: changed from alas to Antoine Martin
Status: newassigned

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

comment:21 Changed 3 months ago by 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).

comment:22 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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.

comment:23 Changed 3 months ago by 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.

comment:24 Changed 3 months ago by 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.

comment:25 Changed 2 months ago by maxmylyn

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.

Last edited 2 months ago by maxmylyn (previous) (diff)

comment:26 Changed 2 months ago by maxmylyn

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
Last edited 2 months ago by maxmylyn (previous) (diff)

comment:27 Changed 2 months ago by Antoine Martin

Owner: changed from alas to maxmylyn

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?

comment:28 Changed 2 months ago by maxmylyn

Owner: changed from maxmylyn to alas

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.

comment:29 Changed 6 weeks ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.