Nixpkgs: USB redirection not working in gnome-boxes, missing PolicyKit file from spice-gtk?

[kamidon]

Issue description

I'm trying to use USB redirection in gnome-boxes to attach a host device to a VM. When I do that gnome-boxes indicates that USB redirection has failed and I see the following messages in the system log:

Apr 18 11:17:11 kea-laptop org.gnome.Boxes[1591]: spice-client-glib-usb-helper: Error PoliciKit error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.spice-space.lowlevelusbaccess is not registered

Steps to reproduce

• Start gnome-boxes
• Start a VM
• Select "Hamburger Menu" -> Properties menu item
• Select the "Devices and Shares" tab
• Toggle the redirect control for an available device you can afford to detach from your host to "Yes"
• Observe error "Redirection of USB device X for VM Y failed." in the interface.
• Use the command journalctl -b SYSLOG_IDENTIFIER=org.gnome.Boxes to see the error output above.

Technical details

Output of nix-shell -p nix-info --run "nix-info -m":

 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.33, NixOS, 18.09pre135256.6c064e6b1f3 (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.0`
 - channels(root): `"nixos, nixos-unstable"`
 - channels(amidon): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

I did some digging and tried to solve this myself but get stuck. The immediate problem appeared to be that the required PolicyKit action file isn't available. It appeared to be provided by the spice-gtk. Inspecting the log for the current hydra build of that package seems to show it wasn't being installed into the store path correctly:

[amidon@kea-laptop:/etc/nixos/overlays/20_picnicpark]$ nix log nixpkgs.spice-gtk
... much deleted ...
make[3]: Entering directory '/build/spice-gtk-0.34/data'
make[3]: Nothing to be done for 'install-exec-am'.
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/mkdir -p 'share/polkit-1/actions'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/install -c -m 644 org.spice-space.lowlevelusbaccess.policy 'share/polkit-1/actions'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/mkdir -p '/nix/store/s3mlp5nlb13jxcay6vjgzcn1r5wwjrjw-spice-gtk-0.34/share/vala/vapi'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/install -c -m 644 spice-protocol.vapi '/nix/store/s3mlp5nlb13jxcay6vjgzcn1r5wwjrjw-spice-gtk-0.34/share/vala/vapi'
make[3]: Leaving directory '/build/spice-gtk-0.34/data'
... more deleted ...

Notice that the polkit file seems to be installed locally in the build directory instead of into a store path.

I tried working around this with the following overlay:

self: super:
{
  spice-gtk = super.spice-gtk.overrideAttrs (oldAttrs: rec {
    PKG_CONFIG_POLKIT_GOBJECT_1_POLICYDIR = "$(out)/${oldAttrs.PKG_CONFIG_POLKIT_GOBJECT_1_POLICYDIR}";
  });

which did result in the file being written where I think it should be:

[amidon@kea-laptop:/etc/nixos/overlays/20_picnicpark]$ sudo nix log nixpkgs.spice-gtk
... much deleted ...
make[3]: Nothing to be done for 'install-exec-am'.
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/mkdir -p '/nix/store/fp3yh7fb0qs4585r4mk6z13f024qymdn-spice-gtk-0.34/share/polkit-1/actions'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/install -c -m 644 org.spice-space.lowlevelusbaccess.policy '/nix/store/fp3yh7fb0qs4585r4mk6z13f024qymdn-spice-gtk-0.34/share/polkit-1/actions'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/mkdir -p '/nix/store/fp3yh7fb0qs4585r4mk6z13f024qymdn-spice-gtk-0.34/share/vala/vapi'
 /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/install -c -m 644 spice-protocol.vapi '/nix/store/fp3yh7fb0qs4585r4mk6z13f024qymdn-spice-gtk-0.34/share/vala/vapi'
make[3]: Leaving directory '/tmp/nix-build-spice-gtk-0.34.drv-0/spice-gtk-0.34/data'
... more deleted ...

What I thought should happen at this point is that the following statement from the polkit NixOS module should cause this file to be linked into /run/current-system/sw/share/polkit-1/actions when nixos-rebuild switch is run:

    # The polkit daemon reads action/rule files
    environment.pathsToLink = [ "/share/polkit-1" ];

However, this is not happening:

ls -1 /run/current-system/sw/share/polkit-1/actions/org.spice-space.lowlevelusbaccess.policy
ls: cannot access '/run/current-system/sw/share/polkit-1/actions/org.spice-space.lowlevelusbaccess.policy': No such file or directory

I have tried to trace through how the linking is done but I've gotten lost and haven't been able to figure it out. I'd greatly appreciate help!

[kamidon]

@xeji , mentioning you on this issue since it looks like you made the most recent changes to the spice-gtk package and I'm hoping you might have some context on what is required to fix the problem.

[jtojnar]

The polkitdir path change was done by me in 82f626702314928c9c8f4ea309430e3aa0680d57, for make-based projects, using $(out) in the variable is acceptable solution (did the same e.g. in fe21f168572e7033257ddd83605a417ad3fa8954).

The path should be linked correctly with security.polkit.enable = true;.

I if is not, spice-gtk is probably not listed in systemPackages, maybe we need to add it to gnome-boxes’s propagatedUserEnvPkgs.

[kamidon]

Thanks for the quick response @jtojnar! I did have security.polkit.enable = true; and I thought I had tried adding spice-gtk directly to systemPackages and that it hadn't worked. But, I must have done it while there was still some other problem in my override because when I added it directly to systemPackages now the file was symlinked into /run/current-system/sw/share/polkit-1/actions. Thanks for prompting me to try again.

As soon as I have enough time I'll try adding spice-gtk to gnome-box's propagatedUserEnvPkgs and if that works I'll post a PR with a patch with those changes.

[kamidon]

PR is here: https://github.com/NixOS/nixpkgs/pull/39133

[kamidon]

In the NixOS community is the general practice to keep bugs open until the channel updates and they can be verified in the release or just close them once the commit has been merged? I'm fine with either in this case, just want to align what I do with the community.

[xeji]

They're usually closed when the pull request is merged.

[kamidon]

Closing since the fix has been merged.

[halturin]

seems this problem is still here. my current setup is unstable and got absolutely the same problem with the same error message in error log

[halturin]

forgot to mention... i'm running on the kernel 5.8. everything else is the default from the unstable channel