[Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest

[Marc-André Lureau]

Hi

----- Original Message -----
> On Tue, Jan 09, 2018 at 11:08:44AM -0500, Marc-André Lureau wrote:
> > ----- Original Message -----
> > > 
> > > What makes spice different here is that it's used to access a VM, and a
> > > VM is supposed to give you isolation. If some hostile code is running in
> > > the VM, its impact on the host/client OS should be minimal. The fact
> > > that a VM with an open client connection can monitor everything that
> > > goes in the clipboard breaks that isolation. For example, I have a ton
> > > of password going through my clipboard, which I don't necessarily want
> > > VM to have direct access to.
> > 
> > Spice isn't that tied to the VM or isolation concept. It's a remote
> > display protocol, aiming to blur the lines between remote and locate
> > applications or desktop. As such, it's not that different from say,
> > the X protocol or the Wayland protocol...
> 
> In theory it's not tied to VMs, in practice, 90% of the time (and I'm
> being conservative) it's used to access VMs.
> 
> > > > I am not that familiar with Wayland clipboard behaviour, could you
> > > > explained what changed? That could help me to understand this patch
> > > > better.
> > > 
> > > I'll detail this in the commit log, but if you try the 'watch' command
> > > from above in a VM, then copy something to your clipboard on the client,
> > > you'll notice that the clipboard content shows up in the VM only after
> > > you give it focus. In a way, this answers your "this shouldn't be solved
> > > at the spice/spice-gtk level" concern, and this was indeed solved at a
> > > different level. However, we still have the issue on x11 for now.
> > 
> > Ok, but then I think we should accept the fact that this is a x11
> > "limitation", like many others x11 security issues. If not, try to fix
> > it at a different level, like the toolkit.
> 
> For most applications using gtk+, this really is a non-issue, or
> something not really important, so it does not really make sense to do
> that at the gtk+ level. spice on the other hand takes local clipboard
> data, and forwards it remotely, so I think it makes sense that it's
> careful with what it does with it.

I think it's problematic for traditional applications as well. clipboard access is probably going to be limited by default and only accessed through so-called "portals", just like file access etc. This topic should be brought on desktop / flatpak mailing list.

Thus I don't believe the problem should be solved at spice-gtk level, as this can potentially break some use cases, like clipboard managers running in the guest etc