search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

Global Config: `Unexpected policy file contents` message at top of USB Devices window #9433

Open andrewdavidwong opened 2 months ago

andrewdavidwong commented 2 months ago

How to file a helpful issue

Qubes OS release

4.2

Brief summary

When I open Qubes OS Global Config and select USB Devices on the left, there's a red box at the top with a message about Unexpected policy file contents.

Steps to reproduce

  1. Open Qubes OS Global Config.
  2. Select USB Devices in the menu on the left.

Expected behavior

No warnings or errors about unexpected policy file contents (or an explanation of what the problem is and what, if anything, should be done about it).

Actual behavior

1

Text version:

Unexpected policy file contents:
Unexpected policy rule: qubes.InputMouse    *   sys-usb @adminvm deny
Unexpected policy rule: qubes.InputKeyboard *   sys-usb @adminvm deny
Unexpected policy rule: qubes.InputTablet *    sys-usb @adminvm deny

Commentary

It's not obvious to me where these rules came from or what's wrong with them.

Let's try a grep:

$ grep -r 'qubes.InputTablet' /etc/qubes/policy.d/*
/etc/qubes/policy.d/50-config-input.policy:qubes.InputTablet * sys-usb dom0 deny
$

Okay, it looks like qubes.InputTablet is present in only one place: 50-config-input.policy. This appears to be a default policy file that was created by Qubes OS. As far as I know, I've never touched this file. I put all of my custom rules in 30-user.policy. I also don't have any qubes.InputTablet rules of my own, or else they would've shown up in the grep results.

alimirjamali commented 2 months ago

It would be helpful if we could see what is below the red box. The screen snapshot does not show that.

andrewdavidwong commented 2 months ago

It would be helpful if we could see what is below the red box. The screen snapshot does not show that.

Why would that be helpful? I excluded it because I thought it was irrelevant.

alimirjamali commented 2 months ago

Why would that be helpful? I excluded it because I thought it was irrelevant.

GUI Widgets are usually in order (from left to right, top to bottom). Having a clue on the failing widget should allow easier troubleshooting while inspecting the Glade files. It should be something like this:

Global_settings

I would like to know what is failing there. The USB Qube query or the 3 drop-down menus down. I suspect the former. But I want to be sure.

andrewdavidwong commented 2 months ago

I think you might be right. Another reason I didn't want to include this portion is because my USB qube name is not sys-usb, and I don't wish to disclose the name publicly. Here's the text version of what appears in that section:

USB qube            *******
Keyboard:           disable
Mouse:              disable
Touchscreen/tablet: disable
marmarek commented 2 months ago

my USB qube name is not sys-usb

I think this is the key information. Yet the rules are about sys-usb (I assume added by the installer, when it created sys-usb which you later removed/renamed).

IMO in this situation (expected set of input-proxy rules for no longer existing USB qube) the message should be different, like "found rules for not existing USB qube, they will be removed when saving changes on this tab", or something like this.

@marmarta what do you think?

alimirjamali commented 2 months ago

I believe I have a clear idea on what is happening here. The errors belong to usb_input_problem_warn_label GtkLabel widget in Glade file. Which is imported as InputDeviceHandler.warn_label in code. And the errors are appended to the label due to this condition which is commented as non-fatal (minor bug). This makes sense. sys-usb is renamed here.

alimirjamali commented 2 months ago

Yes. I can reproduce the bug:

global_config2

One approach to fix it would be be to ignore stock policies for sys-usb in the condition. Another approach would be providing a better message to user to comment-out the stock policies.

marmarta commented 2 months ago

I don't think we should ignore policies completely - but I think the approach with "this contains policies for a non-existent qube" is better. Not sure if we should discard them completely... there could be some interaction with backup/restore that leads to unexpected configuration loss here?

Also, it would be nice to have a single place in the system to define which one is a sys-usb (I know we can't, but a girl can dream, right?)

alimirjamali commented 2 months ago

Also, it would be nice to have a single place in the system to define which one is a sys-usb (I know we can't, but a girl can dream, right?)

This might be doable. The same mechanism that detects PCI USB Controllers and attaches them to the stock sys-usb could be used to detect qube (or qubes) with attached USB Controllers.

marmarek commented 2 months ago

detect qube (or qubes) with attached USB Controllers.

This is more or less what the global config already does to list USB qubes on this screen. It does with multiple of them too (for example I have one per controller on one of my system and it works just fine).

marmarta commented 2 months ago

Yeah, but I'd like for things to magically happen when a user connects a USB controller to a qube. Automatically - or with a question - modified policies etc. But I think this could open problems in edge cases.