| Summary: | RFE: Unify copy-paste behaviour of multimedia files: client/client vs. client/guest | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Radek Duda <rduda> | ||||
| Component: | spice-vdagent | Assignee: | Default Assignee for SPICE Bugs <rh-spice-bugs> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | SPICE QE bug list <spice-qe-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 8.1 | CC: | astepano, dblechte, fziglio, jjongsma, mtessun, rbalakri, tpelka, uril, victortoso | ||||
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened | ||||
| Target Release: | 8.1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-07-09 19:09:15 UTC | Type: | Feature Request | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1247535, 1341092 | ||||||
| Attachments: |
|
||||||
Created attachment 1207529 [details]
python script for copy-paste testing
From my point of view this is not really needed. The Guest-VM is only a display on the client, so C&P should work the same as between two physical systems, which is have the file either on a shared storage or one needs to copy the file to the guest VM (destination host). Also from a security perspective this could be problematic, as usually the VMs are intended to not being able to receiving rich data from the client. As such I will close this BUG as WONTFIX. Please reopen, if you disagree and provide business justification for this. Thanks, Martin Hi Martin, I appreciate you point of view. I think that, Copy-Paste should work as expected or should not work at all. Can you explain why paste of an image to: * one graphical app is recognized as image * another graphical apps is recognized as file? Currently spice during copy-paste cuts many targets. Target - is a way how a buffer could be interpreted. So, why does spice unpredictable drop only some targets and keep other targets? (In reply to Andrei Stepanov from comment #4) > Hi Martin, I appreciate you point of view. > > I think that, Copy-Paste should work as expected or should not work at all. > You have a point there. Still C&P text is typically something that increases usability for simple tasks (e.g. copy a command from a local document and run it on the guest with no need of retyping it (eventually having typos in there as well). So being able to copy plain text is a usability improvement and does not oppose any security threat. > Can you explain why paste of an image to: > * one graphical app is recognized as image > * another graphical apps is recognized as file? As I understood this, the graphics is only recognized locally, but not via spice. So internal within the machine this does work, across machines it does not work. Or do I miss something here? > > Currently spice during copy-paste cuts many targets. Target - is a way how a > buffer could be interpreted. > > So, why does spice unpredictable drop only some targets and keep other > targets? AFAIK spice currently only keeps very few targets or am I mistaken here? So most targets are dropped anyways. So the question is: In case vdagent is enabled, do we want c&p work with every target the host OS can handle? What would that have for implications (Windows is different than Linux, is different than MacOS, probably also Gnome and KDE and other DEs do differ again. @David: What is your take on this? > As I understood this, the graphics is only recognized locally, but not via spice. So > internal within the machine this does work, across machines it does not work. Or do I > miss something here?
Application-receiver chooses copy-paste target as it wishes: as an image, as text, as file, as UTF-8 string, as BMP, as file name, as PNG, as etc... according to its priority.
Application-sender provides to application-receiver contents of the buffer in the asked form (target).
Application-receiver has a priority list. Applications-receiver free to chose target from target list.
Spice drops some targets, and keeps other targets.
For example:
Original targets on client are: PNG, BMP, FILENAME.
Spice drops: PNG, and keeps: BMP, FILENAME.
oodraw: understands only targets: PNG, FILENAME.
gimp: understands all targets: BPM, PNG, FILENAME.
oodraw - chooses FILENAME, as it cannot understand BMP. -- this is unexpected.
gimp - chooses BMP, receives original image.
If spice left original targets, that oodraw would see original PNG image.
Still work to be done upstream. Moving to 7.7 Note that copy/paste of images should work, in the following scenario: - On client/guest - Open the image using image-viewer/editor (e.g. eog or gimp) - Copy the image to clipboard - On guest/client - Open image editor - Paste the image from clipboard Currently sound/video (as well as many other types) can not be copied (between client/guest) via the clipboard. Also, 'x-special/gnome-copied-files' is currently not a supported type (so one can not copy/paste directly from nautilus). Some further security considerations: What happens if the use copies from an "untrusted" source and has an image/whatever in the C&P buffer that contains malware? Do we invoke security scanning? probably not and we probably even cannot trigger that either. That said, we probably need a configurable to enable/disable this behaviour. By default it should be disabled. The configurable must be on the server side as well, as otherwise the user/malware could work around that. Thanks! Martin |
Description of problem: If multimedia file (image, sound sample, video file etc.) is copied from client VM, user is not able to paste it to relevant multimedia application in guest VM in its original form. Vdagent probably reduces clipboard targets. Version-Release number of selected component (if applicable): client: virt-viewer-2.0-12.el7.x86_64 spice-gtk3-0.31-6.el7.x86_64 guest: spice-vdagent-0.14.0-14.el7.x86_64 spice-gtk3-0.31-6.el7.x86_64 How reproducible: always Steps to Reproduce (for example copy-paste image file): first case - client/client copy-paste 1. Open some file manager (tested with Nautilus) on client 2. Copy (ctrl+c) from here an image 3. Open text && picture editor on client (LibreOffice Writer used) and paste the image (ctrl+p) there -> Image is pasted as image --------------------------------- second case - client/guest copy-paste 1. Open some file manager (tested with Nautilus) on client 2. Copy (ctrl+c) from here an image 3. Open text && picture editor on guest (LibreOffice Writer used) and paste the image (ctrl+p) there -> Instead of real image only path of image file is pasted as text. --------------------------------- Actual results: as ^^ Expected results: Behaviour of both cases is unified. If image file is copied from nautilus in client, it should be pasted as image in LibreOffice Writer. Additional info: Clipboard targets can be listed by simple python script: import gtk clipboard = gtk.clipboard_get() clipboard.wait_for_targets() first case output: ('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'x-special/gnome-copied-files', 'text/uri-list', 'UTF8_STRING', 'COMPOUND_TEXT', 'TEXT', 'STRING', 'text/plain;charset=utf-8', 'text/plain') second case output: ('TARGETS', 'UTF8_STRING', 'text/plain;charset=UTF-8', 'text/plain;charset=utf-8', 'STRING') I also attach a python script for copy-paste testing.