We’re running Whonix under Proxmox and with the upgrade to Whonix 18 we’ve been bitten by the lack of support for clipboard sharing under Wayland.
There’s a hacky workaround which uses the VBoxClient (and another which uses scripts to manually transfer the clipboard contents) but it’s spotty and usually needs you to run it twice which is kinda counter to the purpose for which we’re using it.
In digging around I’ve found that spice-vdagent doesn’t support Wayland currently, but there IS a PR in the pipe to add Wayland support which has been ongoing for about 3 months (there’s also an alternate implementation of spice-vdagent called paprika-vdagent which seeks to be a native Wayland version of spice-vdagent which I’ve also tested but I ran into another, similar issue there).
Decided to do an end-run around it and I’ve built the appropriate branch of spice-vdagent/spice-vdagentd but I’m having issues with getting it to actually run, I’m guessing it’s going to be down to some of the hardening on the Whonix images but I’ve not been able to determine WHAT…
I’ve replaced the spice-vdagent(.dist-orig) and spice-vdagentd executables with my custom builds (ensuring that the permissions and such are set the same as the originals) but spice-vdagentd is failing to come up, throwing an error at startup;
`Fatal could not create the server socket /run/spice-vdagentd/spice-vdagentd-sock: Error binding to address (GUnixSocketAddress): Address already in use`
lsof doesn’t show any reference to /run/spice-vdagentd/spice-vdagentd-sock which would tend to suggest that it’s NOT in use, so I’m assuming this is being blocked by something else and that’s being (mis)interpreted as it being in use.
I’ve had a look around in the apparmor profiles and installed auditd to check for SECCOMP audit failures but I’m not seeing anything there so I’m a bit at a loss.
Is anybody able to suggest why I might be having this issue? And how I might go about fixing it
I think this error appears if a UNIX socket still exists on disk when something tries to bind to it, even if there isn’t anything actually listening on it. Try just removing the old socket with sudo rm /run/spice-vdagentd/spice-vdagentd-sock, then try to start your custom binary again.
Note that if you want to avoid your custom binary being blown away by a future software update, you will probably need to install it to a different location than the original, create your own systemd unit to launch it, then mask the original unit.
Thanks, yeah, I already tried deleting the socket and it made no difference (which is largely why I’m thinking there’s something else going on here)
Yup, I’ll address the persistence issues after I get the thing working (and hopefully the wayland branch of vd_agent will get merged into mainline sooner rather than later then I don’t have to worry about it any more)
Follow qemu:///session installation way (if needed):
Note: the part of file transfer or drag/drop or clipboard share have not been upgraded yet to qemu:///session (still using old wiki which was explaining qemu:///system).
Bear in mind that my host isn’t pure KVM (it’s Proxmox) so there may be some differences in my environment though theoretically that shouldn’t matter to this stuff as it all comes through a virtio serial port in any case.
FWIW the client I’m using to connect to the Whonix VM is noVNC 1.7.0-1 and the VM is configured with display=qxl,clipboard=vnc
To build the fixed binaries (in a sysmaint session on Workstation):
sudo apt install git git clone https://gitlab.freedesktop.org/v-dermichev/vd_agent.git cd vd_agent git switch vd_agent_proposal_wlr sudo apt install libgio-2.0-dev libxfixes-dev libxrandr-dev libxinerama-dev libx11-dev libwayland-dev libspice-protocol-dev libalsa-ocaml-dev libdrm-dev ./autogen.sh –with-wayland=yes make sudo make install
Disable and stop the packaged spice-vdagentd;
sudo systemctl disable –now spice-vdagentd sudo systemctl mask spice-vdagentd.socket ps ax | grep spice # get pid of spice-vdagent kill <PID of spice-vdagent>
Then I manually tested by running these commands in two separate Terminal tabs;
I need to double check but I’m pretty sure that the binaries run fine on another clean Whonix image without installing additional dependencies.
For the systemd units I’m just going to mask/disable all the stock spice-vdagent/spice-vdagentd units and create a duplicate set called spice-vdagent-custom/spice-vdagentd-custom which point at the newly built binaries and pass the alternate socket path.
Theoretically the only one that actually needs replacing is spice-vdagent (the daemon doesn’t care if it’s talking to a client in a wayland session) but if you have mismatched spice-vdagent/spice-vdagentd versions the client will refuse to connect so I had to use new versions of both.
Oh, and I can’t confirm whether resolution changes and such work with this client (no reason to believe they shouldn’t, the support is there in code) as that wasn’t working in my environment even with an x11 guest.
I mean, essentially I’m just replacing spice-vdagentd/spice-vdagent with versions which will theoretically exist in future assuming that PR gets merged into mainline so the only “unclean” part of it is that it’s not gone through the standard packaging process
Vis the Whonix on Proxmox stuff, I can put something together but that’s probably better in a different thread.
