Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qubes Clipboard transfer limited size of text #5220

Closed
Nurmagoz opened this issue Aug 6, 2019 · 15 comments · Fixed by QubesOS/qubes-gui-agent-linux#217
Closed

Qubes Clipboard transfer limited size of text #5220

Nurmagoz opened this issue Aug 6, 2019 · 15 comments · Fixed by QubesOS/qubes-gui-agent-linux#217
Assignees
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@Nurmagoz
Copy link

Nurmagoz commented Aug 6, 2019

Qubes OS version

4.0.1

Affected component(s) or functionality

Qubes Clipboard VMs fetcher?

Brief summary

Copying large texts will show 0 bytes in return, and not copying anything.

To Reproduce

Go to any .txt with size lets say 100mb then select all ctrl+a and then ctrl+shift+c it will show 0 bytes been copied

Expected behavior

It should copy the text regardless its size

Actual behavior

Doesnt copy it

Screenshots

N/A

@Nurmagoz Nurmagoz added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Aug 6, 2019
@marmarek
Copy link
Member

marmarek commented Aug 6, 2019

The limit is intentional, to protect both disk space, and target application you paste it to.
It's about 64k

@marmarek marmarek closed this as completed Aug 6, 2019
@marmarek marmarek added the R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken. label Aug 6, 2019
@Nurmagoz
Copy link
Author

Nurmagoz commented Aug 6, 2019

any easy method to increase that ? at least it should be an optional.

Making it as a default sound fine , making it unchangeable sound unusable to some extent.

@marmarek
Copy link
Member

marmarek commented Aug 6, 2019

You can transfer larger data using a file. If your use case is dom0 yournalct, then you can do qvm-copy-to-vm from dom0 too.
BTW looking at your next report #5221 , this is exactly why the limit is there - it's way too easy to break arbitrary application by simply pasting a lot of data.

@Nurmagoz
Copy link
Author

Nurmagoz commented Aug 6, 2019

because there is a bug and i need to search in the logs which i copied to.text in Dom0 i cant do that because there is no gui file editor in dom0(which i like to use more than UI like nano or vim).

@sjvudp
Copy link

sjvudp commented May 26, 2021

any easy method to increase that ? at least it should be an optional.

Making it as a default sound fine , making it unchangeable sound unusable to some extent.

Well, I'd consider 100 MB a bit large, but 64kB also a bit small. The typical user doing cut&copy|paste will have small chunks, agreed, but (just for example) in X11-Emacs it's quite easy to make a big selection (e.g. to copy text from one window to another).
Why not make the limit configurable? After all we don't have a 16-bit system here...

@adrelanos
Copy link
Member

Could this limit (optional or setting) please be increased to something more reasonable let's say... 10 MB?

@DemiMarie
Copy link

@marmarek thoughts?

@DemiMarie DemiMarie reopened this Apr 16, 2022
@unman
Copy link
Member

unman commented Apr 16, 2022 via email

@brendanhoar
Copy link

The limit is intentional, to protect both disk space, and target application you paste it to.

Is the implication here that clipboard data is being saved to dom0 filesystem when clipboard copying from domU A to domU B?

If so, is this really necessary?*

If not, what is the disk space concern?

B

  • again, forensics concerns; dom0 shouldn't purposefully store data that isn't necessary.

@sjvudp
Copy link

sjvudp commented Apr 16, 2022 via email

@andrewdavidwong andrewdavidwong added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: core ux User experience and removed T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken. labels Apr 16, 2022
@andrewdavidwong andrewdavidwong added this to the Release TBD milestone Apr 16, 2022
@logoerthiner1
Copy link

The limit is intentional, to protect both disk space, and target application you paste it to.

Is the implication here that clipboard data is being saved to dom0 filesystem when clipboard copying from domU A to domU B?

If so, is this really necessary?*

If not, what is the disk space concern?

B

* again, forensics concerns; dom0 shouldn't purposefully store data that isn't necessary.

See https://github.com/QubesOS/qubes-gui-daemon/blob/8552d9984efd5017799d526b3c1d13c76c7e0022/gui-daemon/xside.h#L29, when you "Ctrl-Shift-C", the clipboard will be stored inside dom0 /var/run/qubes/qubes-clipboard.bin file. There seems to be an alternative implementation of clipboard (qrexec) but this does not seem to be used actively.

I do not understand in detail the security consequence of storing a controlled blob inside a LUKS-LVM-ext4 partition (/var/run/qubes is not a tmpfs if I get it correct). However it is a valid point to consider that storing clipboard data to that place is suboptimal for forensics concerns.

The source code is really old. I guess that the decision with a /var/run/qubes/qubes-clipboard.bin was done when Qubes OS was ever born. (The last editing of that line is 6 years ago where the line was in xside.c, and another 3 years ago the dash was underscore then.)

Anyway it may not be late to reconsider the design.

@rustybird
Copy link

/var/run/qubes is not a tmpfs if I get it correct

/var/run is a symlink to the /run tmpfs.

@logoerthiner1
Copy link

/var/run/qubes is not a tmpfs if I get it correct

/var/run is a symlink to the /run tmpfs.

Yeah you are right. Then there should be little forensics concerns unless one considers the possibility that tmpfs file is swapped (this could happen though; dom0 is not short of interfaces that can at least give dom0 memory pressure, for example qubes-gui-daemon). "Disk space" is misleading here - actually the capacity of tmpfs is limited mostly by memory space.

@alimirjamali
Copy link

PR for #9296 should fix half of this issue (configurable global clipboard size per GUIVM and/or per qube up to 256KiB). This already quadruples the existing limit.

Over that amount, we have to decide if X11 INCR protocol has to be supported for inter-vm clipboard mechanism. If not, simply reject it. But since the patch for #9296 is relatively big and hard to review, it would be better to wait for its conclusion before dealing with INCR.

alimirjamali added a commit to alimirjamali/qubes-gui-agent-linux that referenced this issue Oct 21, 2024
Warn user if vmside clipboard size is over 256KiB reverting to INCR

fixes: QubesOS/qubes-issues#5220
@alimirjamali
Copy link

PRs #9296 now covers all of this issue.

Patch to gui-daemon creates a .metadata JSON file which includes comprehensive information for Global Clipboard systray widget.

For the handling of X11 INCR (clipboard size over 256KiB), the patch to gui-agent converts it to a meaningful warning rather than sending a meaningless byte.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
Development

Successfully merging a pull request may close this issue.