[Spice-devel] Fix filter string behaviour to be more intuitive before lots of people start depending on it

[Hans de Goede]

Hi,

On 05/31/2012 03:34 PM, David Jaša wrote:
> SSIA
>
> The current "grandfathered" filter format behaves counter-intuitively.
> Let me describe it based on my experiments:
>       1. there is a "hard default" that disables all devices (aka
>          -1,-1,-1,-1,0), it must be always overwritten if you wish to
>          auto-share anything. This is not advertised anywhere

AFAIK this is the same behavior as the filter for incentive pro, the
filter format is based on that of incentive pro, so the things like
the filter-editor tool and old filters can be reused.

More importantly then the "incentive pro did it this way" argument though,
is that it is a safe default from security pov. These filter strings are
used in more then one place:

1) In the client to decide which devices to auto-redirect when new devices
    are hotplugged
2) In the client to specify (already plugged in) devices to redirect on
    client connect (*)
3) On the qemu cmdline to specify which redirected devices will be accepted

*) Not yet available, to be implemented soon.

For 2 and 3 deny by default clearly is the right policy, for 2 having a
redirect everything that does not match policy means redirecting all
devices the client has on client connect, not good. For 3 an allow by
defautl policy is simple not an option from a security pov.


>       2. there is a "soft default" that enables everything but HID
>          devices (aka 3,-1,-1,-1,0|-1,-1,-1,-1,1)
>       3. when user specifies a custom filter string, it
>                * replaces string from #2
>                * is based on top of #1
>
> All combined together cause unexpected behaviours like the one described
> in https://bugzilla.redhat.com/show_bug.cgi?id=823541 .
>
> The most straightforward fix seems to get rid of "soft default" #2 and
> use its value in "hard default" #1. That way, when user specifies
> --spice-usbredir-filter="11,-1,-1,-1,0", the effective filter string
> will be what user will expect:
> "3,-1,-1,-1,0|11,-1,-1,-1,0|-1,-1,-1,-1,1"
>
> instead of current behaviour where such string will become
> "11,-1,-1,-1,0|-1,-1,-1,-1,0", effectively block-all "-1,-1,-1,-1,0"
>
> Hans, do you think this is doable in a short time frame? If it is not
> done this way soon, people will constantly ask about that...

Doable yes, desirable no. Having a default policy is one thing, but
mandatory adding (in a very hidden way) "11,-1,-1,-1,0" to any
filter is just plain wrong, as it will surprise the user.

And as discussed above I believe that an allow by default if nothing
matches the given filter is a bad idea!

Regards,

Hans