Unable to use Qubes Updates on `sys-gui`: [Errno 13] Permission denied

[peakunshift]

Qubes OS release

4.2.0

Brief summary

When using sys-gui there is a permission error that prevents Qubes Updates to open.

I'm reporting this specific issue but it's not the only app with this error. I started a topic on the forum around a more general discussion regarding admin privileges for GuiVMs: https://forum.qubes-os.org/t/grant-full-admin-privileges-to-sys-gui-sys-gui-gpu/

Steps to reproduce

• Install sys-gui and log into it
• Open Qubes Updates

Expected behavior

• Qubes Updates opens as expected

Actual behavior

Permission error reported on the Bug Report UI tool of sys-gui:

backtrace
__init__.py:1213:_open:PermissionError: [Errno 13] Permission denied: '/var/log/qubes/qui.updater.log'

Traceback (most recent call last):
  File "/usr/bin/qubes-update-gui", line 33, in <module>
    sys.exit(load_entry_point('qui==0.1', 'gui_scripts', 'qubes-update-gui')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/qui/updater/updater.py", line 303, in main
    app = QubesUpdater(qapp, cliargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/qui/updater/updater.py", line 47, in __init__
    log_handler = logging.FileHandler(
                  ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/logging/__init__.py", line 1181, in __init__
    StreamHandler.__init__(self, self._open())
                                 ^^^^^^^^^^^^
  File "/usr/lib64/python3.11/logging/__init__.py", line 1213, in _open
    return open_func(self.baseFilename, self.mode,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/var/log/qubes/qui.updater.log'

[ZYousef]

Make sure that /var/log/qubes/ directory exists, or run as sudo. However, I do not think the update would still work anyway as the backend is still not supported - (qubesctl is in dom0)

[marmarek]

In fact, there is a PR that drops last usage of qubesctl in updater: https://github.com/QubesOS/qubes-desktop-linux-manager/pull/181 So, in theory (after fixing directory permissions) updating templates from sys-gui should work (but not updating dom0, yet).

[peakunshift]

Thanks for your answers!

I raised this issue about Qubes Updates to have one single, actionable thing but my issue is also about permissions in the GuiVM. I shared two other similar issues on the Forum post (with Blueman and Policy Editor).

Given the fact that we don't have access to dom0 in sys-gui-gpu, I suppose other VMs need to have full admin privileges (either the GuiVM, an AdminVM, or multiple ones). It's not clear for some of us what is planned and what contribution is needed.

I can send an email to qubes-devel to discuss it if it's more appropriate!

[marmarek]

Running qubes-vm-update from outside of dom0 currently doesn't work. If nothing else, then because it is packaged for dom0 only. Theoretically, it could work with enough qrexec permissions (at least full qubes.VMExec access), but I think we can do better: create a service in dom0 that will call qubes-vm-update for a specific qube. This way, you can apply updates from GUI domain, without giving it full control over the target. This isn't strictly necessary in the default "GUI domain with full permissions" case, but it will be relevant for more restricted cases.

I think the easiest way would be to keep target selection on the client side (GUIVM in this case), so it's really a simple qrexec service without complex arguments (that would be needed for target selection otherwise). And it could passthrough update agent data from the target qube to the caller, so the caller could nicely render progress info with mostly unmodified code. If more qubes are selected to be updated, several calls (some possibly in parallel - depending on settings) can be made. That service could use a trick we have in Admin API for target info - have the policy specify target=dom0, and then the service use "requested target" for the actual target info. This way it's possible to use tags etc for target policing (which wouldn't be possible if qube name would be in the service argument).

@piotrbartman

[rapenne-s]

This is a reasonable proposal to me.