This is a cross post of https://bugzilla.redhat.com/show_bug.cgi?id=2016563 SUMMARY Cannot copy from wayland application under KDE guest VM to host STEPS TO REPRODUCE 1. Install Fedora 42 KDE guest vm in virt-manager 2. In guest vm , open KWrite and type some words, and select all and Ctrl + C to copy thest words 3. In host (whatever OS) open any text editor, Ctrl + V to paste OBSERVED RESULT No text copied. EXPECTED RESULT Text copied from guest vm to host. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 42 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 ADDITIONAL INFORMATION The problem is that most vm agent (spice-vdagent , open-vm-tools) could only handle X11 clipboard events. They know nothing about wayland clipboard (unless they implemented ext-data-control / wlr-data-control protocol ) If a wayland compositor implements features like transfering wayland clipboard event to X11, then the vm agent will work. Gnome implemented the feature. Kwin implemented this feature too however there's a limiation for security to prevent snooping: if an x11 application doesn't have active windows, it won't be able to receive wayland selection. Here are some solutions: 1. KWin(Compositor side) : remove restrictions on no active window X11 application to receive wayland selection , ie https://invent.kde.org/jackyzy823/kwin/-/compare/master...spice_vdagent_copy?from_project_id=2612. Pros: 1) Works for different VM agent solution (if the agent works with x11 clipboard) Cons: 1) security. I know there are security implications of reading a clipboard . (However GNOME allows this) This patch works under spice-vdagent / open-vm-tools / virtualbox-guest-additions (7.1.6 / not work under 7.1.8+ host paste action will hang) 2. Bridge: Use third party tools which could read from wayland clipboard (via ext-data-control or wlr-data-control) and then set to X11 clipboard like https://github.com/dnut/clipboard-sync Pros: 1) Works under different Wayland compositor which supports ext-data-control or wlr-data-control and different VM agent solution (if the agent works with x11 clipboard) Cons: 1) No out-of-box experience 2) not all distrubtions package similar tools and make autostart file for them. 3. VM Agent side: update vm agent to implement either a) like clipboard-sync get from wayland clipboard (via ext-data-control protocol) then set to X11 clipboard OR b) do the thing like kwin but without restrictions. Pros: security. accessing wayland clipboard via ext-data-control/wlr-data-control protocol. Cons: 1) need to be implemented in different VM agent (spice-vdagent , open-vm-tools and etc ) 2) not all compositor support the necessary ext-data-control/wlr-data-control protocol for the headless vm agent to get wayland clipboard data. 4. or the dummy way: copy text from wayland application in vm to an x11 application in vm (like vscode) and then copy text from x11 application in (can not skip this step) to host. some more word about virtualbox-guest-additions , https://www.virtualbox.org/ticket/20808 says it works , but this comment https://www.virtualbox.org/ticket/20808#comment:4 tests Kubuntu host and Windows Guest which is not our situation. and this https://www.virtualbox.org/ticket/20808#comment:3 may test Kubuntu host with Ubuntu (gnome) guest, which should already works.
Some good useful commits: https://invent.kde.org/plasma/kwin/-/commit/947d2c5ad0746d807b04f6bb382e1d4ddb1b7f29 > Regarding snooping clipboard contents, our SelectionRequest handler has a guard to protect us against that case. https://invent.kde.org/plasma/kwin/-/commit/760e35065ed8b5f570f757cc464473b5f75a3c5b > X11 did not have a requirement that apps needed keyboard focus to update a clipboard. Apps could copy things on click. With context menus and grabs there can be no active window at this point. > Kwin tried to retrofit a requirement, which doesn't work in all cases. > Whilst there are security implications of reading a clipboard there are no security issues about pushing a new clipboard. Gnome also allows X11 apps to push to the clipboard at any point. This commit ease the limitation for copy from host to guest. https://invent.kde.org/plasma/kwin/-/commit/6e08fb2fa5f6f2d03d9ad5ef74519295357c6ba2 https://invent.kde.org/plasma/kwin/-/commit/2776f829efbd0915039e8e4200de6625772b9734 Switch from x sync helper to built in.
> 2. Bridge: Use third party tools which could read from wayland clipboard (via ext-data-control or wlr-data-control) and then set to X11 clipboard like https://github.com/dnut/clipboard-sync > Pros: 1) Works under different Wayland compositor which supports ext-data-control or wlr-data-control and different VM agent solution (if the agent works with x11 clipboard) Edit: wayland compositors should have and enable xwayland feature. otherwise x11 clipboard doesn't exists.
Add a see also to bug 470057 and i don't think this is a vdagent only bug.
It's up to spice-vdagent to fix its Wayland support, we will not add very bad workarounds for this. *** This bug has been marked as a duplicate of bug 470057 ***
So even spice-vdagent implement wayland support , what about open-vm-tools ? what about virtualbox-guest-additions ? -------------------- I think since kwin chooses to sync clipboard from wayland land to x11 land, then it should follow x11 rules. ------------------------ > we will not add very bad workarounds for this. Another question is that: **Does the security limitation really help?** If a malicious program wants to steal wayland clipboard content, it could do it via `ext-data-control` protocol very very easily (just like wl-paste) , this makes the guard in x11 part like a joke.
It does not matter if other tools need to add Wayland support as well. Do not reopen this bug report again. > If a malicious program wants to steal wayland clipboard content, it could do it via `ext-data-control` protocol No, because it's a privileged protocol, and can be filtered out for sandboxed applications.
Ok i won't reopen this. > No, because it's a privileged protocol, and can be filtered out for sandboxed applications. So could we implement a mechanism to allow user to choose which program could get clipboard content without active window? Does this sound reasonable ?
(In reply to jackyzy823 from comment #7) > So could we implement a mechanism to allow user to choose which program > could get clipboard content without active window? Does this sound > reasonable ? I'd support that. I think it'd require a new FR, though.
> | What | Removed | Added | > |------------|----------|-------| > | Resolution | UPSTREAM | FIXED | This isn't FIXED. I think this should be set back to DUPLICATE, like it originally was.
> filtered out for sandboxed applications. I still don't get the point. :( Did you mean flatpak? Could you help to point out the related document about the filter ? I couldn't find document about how to restrict a non-flatpak progam to use `ext-data-control` to visit flatpak application's clipboard. or settings to disable flatpak application to visit clipboard. or is this something not implemented yet but planned to ? *** This bug has been marked as a duplicate of bug 470057 ***
(In reply to jackyzy823 from comment #10) You might get a little more success at KDE's Discourse instance. Generally, that's the place to go before filing a bug, to ensure that its premise is correct.