Xpra: Ticket #2072: Restricting the amount of clipboard data copying from the server clipboard in/out of the client

The goal is to restrict the amount of data being transferred from server in the client (or vice versa - out) through clipboard copy/paste operation.

Two options specifying the max size

  1. max_clipboard_copyin_size (into client - raw to wire)
  2. max_clipboard_copyout_size (out from client - wire to raw)

In addition, notify the client when the data is truncated.



Sat, 08 Dec 2018 04:09:45 GMT - Antoine Martin: owner changed

Please attach the patch.


Mon, 10 Dec 2018 21:50:25 GMT - Calvin Ko: attachment set


Mon, 10 Dec 2018 21:51:33 GMT - Calvin Ko:

attached the patch


Mon, 10 Dec 2018 22:13:06 GMT - Antoine Martin: attachment set

improved patch


Mon, 10 Dec 2018 22:15:43 GMT - Antoine Martin:

The updated patch changes:

@calvinko: this modifies a private clipboard method, please include the changes that call it.


Tue, 11 Dec 2018 19:14:38 GMT - Calvin Ko: attachment set

patch with control command to set the size limits


Tue, 11 Dec 2018 19:16:28 GMT - Calvin Ko:

The update patch - clipboard-size-v2.patch


Tue, 11 Dec 2018 19:38:13 GMT - Antoine Martin:

OK, some minor changes are still needed:

with python3 you probably get an error in the clipboard code on every request (which may be worse as this is known to cause GTK to hang)


Tue, 11 Dec 2018 20:14:17 GMT - Calvin Ko: attachment set

address the minor changes stated in comment:5


Tue, 11 Dec 2018 20:31:55 GMT - Antoine Martin:

As per comment:5:

use None default values for max_send_size and max_receive_size in set_direction

Otherwise regular clipboard clients, which call set_direction without the extra arguments will end up removing the size restrictions.

IMO max_send in setting_changed is redundant and should be called send


Tue, 11 Dec 2018 21:19:06 GMT - Calvin Ko: attachment set

address comment:6


Tue, 11 Dec 2018 22:08:22 GMT - Antoine Martin:

Did you test this? Ideally this feature should be added to the unit tests.

I found at least two major problems during my quick testing:

And this ends up truncating all clipboard packets by 1 character.


How I tested:

Then check that the client does receive a truncated string:

Then the other way (client to server) - preferably after changing the limits to ensure that send and receive limits are used the right way around. Also worth testing: client limits via env vars.


Tue, 11 Dec 2018 22:46:49 GMT - Calvin Ko:

r21202 fixes a long standing bug that is uncovered by the extra "truncated" >attribute in the "clipboard-contents" packets - do you really need this? (it will create backwards compatibility issues with older versions - as some users just don't update as often as they should..)

You are right. I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?


Tue, 11 Dec 2018 22:48:20 GMT - Calvin Ko:

I have not test the code since I don't have an environment set up to test xpra. Lets ask Max to help testing.


Tue, 11 Dec 2018 22:50:04 GMT - Antoine Martin:

I am actually thinking to add a clipboard-content-truncated message instead of changing the clipboard-content packets. All I need is to notify the client in some way. What do you think?

If you need to notify the client, then I would rather not add a new packet type. We can workaround older clients by adding a new capability flag in the hello packet - something like clipboard-contents-slice-fix=true.


Wed, 12 Dec 2018 00:16:01 GMT - Calvin Ko: attachment set

address comment:10


Wed, 12 Dec 2018 00:18:05 GMT - Calvin Ko:

clipboard-size-v5.patch


Wed, 12 Dec 2018 00:21:10 GMT - Calvin Ko: owner changed


Wed, 12 Dec 2018 00:21:59 GMT - Calvin Ko:

Max, see comment:7 for testing.


Wed, 12 Dec 2018 19:27:46 GMT - Antoine Martin:

Merged in r21213 with the following changes:

Backports:


Thu, 13 Dec 2018 22:49:25 GMT - J. Max Mena:

Fired up a trunk r21225 server, and followed the steps for using the control channel - primarily xpra control :DISPLAY clipboard-limits 8 8 and it broke the server side clipboard. I could copy text from my client into the server clipboard, but could not copy anything on the server. If I did, the clipboard would be empty, and I couldn't paste anything client side.

I ran a session with -d clipboard demonstrating what I saw. My repro steps are pretty easy:

I tried that on three different sessions, and it failed each time. I'll work on using the Environment variables and using xclip.


Thu, 13 Dec 2018 22:52:26 GMT - Antoine Martin:

I tried that on three different sessions, and it failed each time.

Failed how? Wrong data? No data? Do you have logs?


Thu, 13 Dec 2018 22:54:01 GMT - J. Max Mena: attachment set

Requested logs.


Thu, 13 Dec 2018 22:57:05 GMT - J. Max Mena:

When I copy from the client to server, I get as much text as I should within the limits - 8 characters. But when I highlight text on the server, copy it, and then paste it client-side, there's no data.

I just installed xclip, and I restarted my server and now it's working?


Thu, 13 Dec 2018 22:59:49 GMT - Antoine Martin:

I just installed xclip, and I restarted my server and now it's working?

What steps? The ones from comment:7 do use xclip so it should not come as a surprise that you need to have it installed.


Thu, 13 Dec 2018 23:00:57 GMT - Antoine Martin:

Always test with the most basic tools, like xclip. Do not trust applications to do the right thing with the clipboard.


Thu, 13 Dec 2018 23:03:44 GMT - J. Max Mena: status changed; resolution set

Noted.

Both the control channel and the environment variables work with xclip, so as far as I can tell there isn't anything else to do.

I'm gonna go ahead and close this, unless there's any follow-ups.


Sat, 23 Jan 2021 05:41:27 GMT - migration script:

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