QubesOS / qubes-issues

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

Global clipboard pasting suddenly stopped working due to qubes-qrexec-policy-daemon.service crash #8077

Open andrewdavidwong opened 1 year ago

andrewdavidwong commented 1 year ago

How to file a helpful issue

Qubes OS release

4.1.1

Brief summary

The global inter-qube clipboard was working fine one minute, then suddenly pasting stopped working. (Copying still worked.)

Steps to reproduce

In my case, I was trying to copy @marmarek's signed comment here so that I could verify it in another qube. ctrl+shift+C still worked normally. I got a notification in dom0 that the text had been copied to the global clipboard. However, nothing happened when I pressed ctrl+shift+V. I tried random text with a bunch of different qube combinations with the same result. It had been working fine minutes ago.

Expected behavior

Normal global clipboard pasting.

Actual behavior

In dom0:

$ cat /var/log/qubes/guid.example-destination-qube.log
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
connect: No such file or directory
$ systemctl status qubes-qrexec-policy-daemon
● qubes-qrexec-policy-daemon.service - Qubes remote exec policy daemon
     Loaded: loaded (/usr/lib/systemd/system/qubes-qrexec-policy-daemon.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2023-03-05 23:33:39 PST; 17h ago
    Process: 3450 ExecStart=/usr/bin/qrexec-policy-daemon (code=exited, status=1/FAILURE)
   Main PID: 3450 (code=exited, status=1/FAILURE)
        CPU: 122ms

Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:     self.load_policy_file(file, path)
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1405>
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:     self.rule_type.from_line(
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1218>
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:     return cls(
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:   File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 1124>
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]:     raise PolicySyntaxError(
Mar 05 23:33:39 dom0 qrexec-policy-daemon[3450]: qrexec.exc.PolicySyntaxError: /etc/qubes/policy.d/30-user.policy:52: invalid>
Mar 05 23:33:39 dom0 systemd[1]: qubes-qrexec-policy-daemon.service: Main process exited, code=exited, status=1/FAILURE
Mar 05 23:33:39 dom0 systemd[1]: qubes-qrexec-policy-daemon.service: Failed with result 'exit-code'.
marmarek commented 1 year ago

I see policy syntax error (with specific line in your file). The service shouldn't crash (that's a bug here), but it wouldn't allow the call either.

andrewdavidwong commented 1 year ago

I see policy syntax error (with specific line in your file). The service shouldn't crash (that's a bug here), but it wouldn't allow the call either.

Oh, I see. Thank you for pointing that out.

That line (line 52) is actually a commented-out policy rule (i.e., a line beginning with a # which, if removed, would result in a policy line). Shouldn't such commented lines be ignored, regardless of whether the rule (if not commented) would have had proper syntax?

marmarek commented 1 year ago

Yes, commented-out line should be ignored, not interpreted. See the service failed 17h ago, maybe it wasn't commented out at that point?

andrewdavidwong commented 1 year ago

Yes, commented-out line should be ignored, not interpreted. See the service failed 17h ago, maybe it wasn't commented out at that point?

Ah, possibly. I could've sworn that global pasting worked since then, but maybe my memory is faulty. (Wouldn't be the first time!)

SaswatPadhi commented 1 year ago

Sounds like this is related to #7043? I keep running into similar issues every now and then when tweaking policies.

The service shouldn't crash (that's a bug here), but it wouldn't allow the call either.

Yes, the Qrexec policy daemon should never crash. Not allowing the RPC call (essentially a $anyvm $anyvm deny for that rpc) is a safe default.