-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qubes manager does not start if any Admin API call is refused #5811
Labels
C: manager/widget
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
T: bug
Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Milestone
Comments
marmarek
added
T: bug
Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
C: manager/widget
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
labels
May 10, 2020
I think this is going to be easier to implement with this PR: QubesOS/qubes-manager#195 ; or if not easier, it seems to be a bad idea to do it before merging that one. |
marmarta
added a commit
to marmarta/qubes-manager
that referenced
this issue
Aug 3, 2020
It should no longer crash if policy denies it access to some information. The only required information is vm name, qid and class. references QubesOS/qubes-issues#5811
marmarta
added a commit
to marmarta/qubes-manager
that referenced
this issue
Aug 7, 2020
It should no longer crash if policy denies it access to some information. The only required information is vm name, qid and class. references QubesOS/qubes-issues#5811
marmarek
added a commit
to marmarek/qubes-core-admin-client
that referenced
this issue
Aug 10, 2020
Rename QubesDaemonNoResponseError to more intuitive QubesDaemonAccessError (keep legacy name still working). Use QubesPropertyAccessError whenever the access is about @Property - this makes it easy to use `getattr` to use default value instead. QubesOS/qubes-issues#5811
marmarek
added a commit
to marmarek/qubes-core-admin-client
that referenced
this issue
Aug 11, 2020
Rename QubesDaemonNoResponseError to more intuitive QubesDaemonAccessError (keep legacy name still working). Use QubesPropertyAccessError whenever the access is about @Property - this makes it easy to use `getattr` to use default value instead. QubesOS/qubes-issues#5811
marmarek
added a commit
to marmarek/qubes-manager
that referenced
this issue
Aug 12, 2020
For QubesDaemonAccessError exception. QubesOS/qubes-issues#5811
This was referenced Aug 12, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C: manager/widget
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
T: bug
Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Qubes OS version
R4.1
Affected component(s) or functionality
qubes-manager
Brief summary
Trying to open qubes manager in a GUI domain with limited permissions fails.
To Reproduce
Steps to reproduce the behavior:
1. Setup sys-gui
2. Open qube manager inside
Expected behavior
Qube manager starts and shows as much info as is available. Info that cannot be retrieved, is marked as unavailable.
Ideally, any failure should be recoverable, but it may be unrealistic in some cases - like failure to getting
qid
(used internally by qube manager). In those cases, I propose either not list such qube at all (and perhaps show some warning on stderr, or some more user friendly place).Actual behavior
Any failure (like, getting dom0's "features") cause qube manager to crash on startup.
Screenshots
Video of this job: https://openqa.qubes-os.org/tests/7988
Additional context
Qube manager running in GUI domain.
The same issue may apply also to qube settings dialog.
Solutions you've tried
Modify policy to give GUI domain every access qube manager needs.
The text was updated successfully, but these errors were encountered: