Allow spaces in values for `qvm-features-request`

[ArrayBolt3]

Qubes OS release

Qubes OS 4.3

Brief summary

qvm-features-request and qubes-core-admin exhibits very strange failure patterns if you call qvm-features-request from inside a template and try to set a key-value pair with a value that contains a space. In essence:

• Setting a key-value pair to a value without a space works.
• Setting a key-value pair to a value that contains a space fails.
• If you try to set a key-value pair to a value that contains a space, subsequent attempts to set a key-value pair to a value without a space may fail.

So far the behavior pattern seems to be reproducible, but somewhat unpredictable.

Steps to reproduce

1. In dom0, kill the qubesd service with sudo systemctl stop qubesd.
2. In dom0, launch qubesd in a terminal with sudo /usr/bin/qubesd -vv for debugging.
3. Launch a template VM, it doesn't matter which one. I'm using fedora-41-xfce, but debian-12-xfce also works.
4. Run the following set of eight qvm-features-request commands, one at a time:

Call 1: Run qvm-features-request abc=def --commit.
Call 2: Run qvm-features-request abc.def=def --commit.
Call 3: Run qvm-features-request abc="def ghi" --commit.
Call 4: Run qvm-features-request abc.def=def --commit.
Call 5: Run qvm-features-request abc=def --commit.
Call 6: Run qvm-features-request abc.def=def --commit.
Call 7: Run qvm-features-request abc.def="def ghi" --commit.
Call 8: Run qvm-features-request abc.def=def --commit.

Expected behavior

All qvm-features-request calls should exit non-zero, regardless of whether they contain spaces or not. The calls should ultimately be no-ops since dom0 has no code to actually set the requested features.

Actual behavior

The following pattern is exhibited, with anomalies bolded:

Call 1: Succeeds.
Call 2: Succeeds.
Call 3: Fails.
Call 4: Fails (even though the value doesn't contain a space).
Call 5: Succeeds.
Call 6: Succeeds (apparently the previous success somehow got this case un-stuck?)
Call 7: Fails.
Call 8: Succeeds (maybe because we're dealing with the same key in both calls 7 and 8?)

Additional information

Every time a successful call is made, qubesd outputs a log message similar to qubes.utils: Renamed file: '/var/lib/qubes/qubes.xml~XXXXXXX' -> '/var/lib/qubes/qubes.xml' (where XXXXXXX are what appear to be random characters). Every time a failed call is made, qubesd outputs a log message like app: permission denied for call b'qubes.FeaturesRequest'+b'' (b'fedora-41-xfce' -> b'dom0') with payload of 0 bytes.

[ArrayBolt3]

Note that this bug blocks implementing QubesOS/qubes-core-admin#653, since we need to be able to request features with values that contain spaces in order for a VM to advertise a boot mode that involves more than one kernel parameter.

[marmarek]

The behavior isn't really surprising - qvm-feature-request stashes all the values to be sent, and sends them on the next --commit (which you do in the same call). It (intentionally) doesn't remove the values prepared to be sent - so, once you save a problematic value, it will cause issues until you override it with non-problematic (and the same key value).

But still, it looks buggy.

[marmarek]

Looks like initial validation refuses spaces: https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/api/misc.py#L96

I think it's okay to allow spaces, but I need to review all the existing handlers of feature requests first...

[ArrayBolt3]

@marmarek Is it useful for me to do that review and report the results, or should I put QubesOS/qubes-core-admin#653 on hold for now? (Just want to avoid duplicating effort.)

[marmarek]

See linked PR. I've checked all places and should be safe.

[ArrayBolt3]

Awesome! Thank you!