[Spice-devel] [PATCH] usbredir: fix redirection of user-accesible device nodes.

[Suchánek Michal]

-----Original Message-----
From: Christophe Fergeau [mailto:cfergeau at redhat.com] 
Sent: Monday, June 29, 2015 4:37 PM
To: Suchánek Michal
Cc: spice-devel at lists.freedesktop.org
Subject: Re: [Spice-devel] [PATCH] usbredir: fix redirection of user-accesible device nodes.

Hey,

On Mon, Jun 29, 2015 at 03:46:56PM +0200, Michal Suchanek wrote:
> This basically reverts 63c8526c699692b6fdca15db8209730fca7eb817
> 
> After this change opening the device node is not tried at all.

Imo this is what should be fixed

> 
> So when user has access to the device node and policykit ACL is not 
> set up access is denied while in fact the device could be accessed.

The log of commit 63c852 is fairly clear that spice-gtk considers the normal case to be ""policykit is setup, usb device node is not accessible to the user". Is this a wrong assumption? Did you have these issues with an out-of-the-box distro installation, or is it some customizations that you are making?

For security reasons the default is that the USB devices are inacessible either by opening the device node or by calling out to the ACL helper.

So to enable redirection I had to customize in one way or another. I chose to add udev rules which add user permission for selected devices. This is one of the standard ways which works cross-distribution and cross-package. TBH I did not even know there is an ACL helper and I should not need to know when I have permission to access the device directly.

As I understand it the ACL helper is spice-specific. Even if it could be used by other application it is not necessarily the case. So the udev rules are a one-stop solution for all USB using applications and should be supported even if policykit support is compiled in.

Or the other way around compiling in policykit support *should not disable* access to already accessible devices.

> The change was made to prevent logging error when opening the device 
> is attempted. However, unless some really complex error processing is 
> implemented logging the error from libusb and displaying the error 
> from ACL helper to the user seems like the best thing we can do.

My understanding is that the issue was that when using policykit ACL (with no access to the device node), trying first to open the device node would cause an error to be logged even if the policykit code would then succeed, ie the libusb error was some kind of 'false-positive'

It's indeed the case. However, this is merely a cosmetic issue while the fix for the cosmetic issue causes a functional error.

Thanks

Michal