qubes-mgmt-salt-vm-connector fails to list dependencies on qubes-core-agent-passwordless-root and socat

[DemiMarie]

Qubes OS version

Qubes release 4.0 (R4.0)

Affected component(s) or functionality

qubes-mgmt-salt-vm-connector packaging

Brief summary

qubes-mgmt-salt-vm-connector should depend on qubes-core-agent-passwordless-root but does not.

How Reproducible

100%

To Reproduce

Steps to reproduce the behavior:

1. Install qubes-template-fedora-32-minimal in dom0
2. Install qubes-mgmt-salt-vm-connector in fedora-32-minimal
3. Create a DispVM template (such as fedora-mgmt-dvm) with fedora-32-minimal as its template.
4. Set the management_dispvm property of fedora-32-minimal to fedora-mgmt-dvm
5. Try to update fedora-32-minimal using Salt, or run qvm-console-dispvm on a VM based on fedora-32-minimal.

Expected behavior

Updates and qvm-console-dispvm work.

Actual behavior

Updates and qvm-console-dispvm fail.

Screenshots

Additional context

Solutions you've tried

Relevant documentation you've consulted

Related, non-duplicate issues

[marmarek]

I'm not sure about socat, but it should be possible to make it work without qubes-core-agent-passwordless-root. Perhaps as simple as adding user='root' argument at dispvm.run_service call

[marmarek]

TBH, I think what user is a service running as should be configurable (also? only?) at the target VM, not dom0 (either in policy, or call argument when call originates from dom0).

[DemiMarie]

socat isn’t needed for Salt, but is needed for qvm-console-dispvm. Since installing qubes-mgmt-salt-vm-connector indicates that one is likely to be using that qube as a management DispVM, it should probably have Recommends: socat.

[marmarek]

/etc/qubes-rpc/qubes.ShowInTerminal belongs to qubes-core-agent - so, this package should have dependency on socat.

[DemiMarie]

TBH, I think what user is a service running as should be configurable (also? only?) at the target VM, not dom0 (either in policy, or call argument when call originates from dom0).

That’s already possible if the service is run as root ― it can drop privileges to any user it chooses.

[marmarek]

That’s already possible if the service is run as root ― it can drop privileges to any user it chooses.

Yes, but currently services by default are started as user (which makes sense in most cases).

[DemiMarie]

I could add another service configuration option.

[marmarek]

That would be perfect. Something like force-user, which override username sent from dom0? Otherwise we'd likely need a protocol change, because currently default user is resolved in dom0 and qrexec-agent has no way to distinguish whether user uesr is there because it is default, or because it was explicitly requested.
Such property would also allow for less hacky qubes.VMRootShell service (currently if you forget to add user=root in the policy, it isn't really a root shell).

Technically, it seems to require a minor refactor, because service config is loaded only within wait_for_session_maybe function.
Anyway, priority-wise, that sounds rather like R4.2 material.

[DemiMarie]

I agree, although once it is implemented I see no reason not to backport it to R4.1.

[marmarek]

Backporting itself - if the change indeed will be simple enough, then we can consider it. But in many cases we couldn't rely on such backport, because inter-VM package dependency tracking isn't a thing.

[DemiMarie]

Closing, since this has been fixed. The qrexec enhancement is tracked as #6354.