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

totaam commented 11 years ago

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

totaam commented 8 years ago

2016-04-24 13:32:06: L29Ah commented

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

totaam commented 8 years ago

2016-04-24 13:37:55: L29Ah commented

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

totaam commented 8 years ago

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.

totaam commented 8 years ago

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.

totaam commented 8 years ago

2016-05-30 07:07:13: antoine uploaded file `clipboard-directions.patch` (38.1 KiB)

mostly complete patch

totaam commented 8 years ago

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?

totaam commented 8 years ago

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.

totaam commented 8 years ago

@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/beta

totaam commented 8 years ago

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

totaam commented 8 years ago

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.

totaam commented 8 years ago

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

totaam commented 8 years ago

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

totaam commented 8 years ago

2016-10-01 01:58:17: afarr uploaded file `xpra-ticket276-to-server-d-clipboard-server-logs.txt` (71.3 KiB)

server logs

totaam commented 8 years ago

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

totaam commented 8 years ago

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

totaam commented 8 years ago