-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Apr 05, 2024 at 02:16:32PM -0400, Demi Marie Obenour wrote: > On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki wrote: > > On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote: > > > Should an empty service argument (qubes.Service+) always be the same as > > > no argument at all (qubes.Service)? Right now, they are the same when > > > coming from a VM, but not when coming from dom0: qubes.Service from dom0 > > > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+ > > > will. > > > > I'd say they should behave the same - the "qubes.Service" call should > > search for /etc/qubes-rpc/qubes.Service+ first. > > Is the "qubes.Service" call actually valid to make? dom0 certainly > makes such calls right now, but I'm wondering if that is a bug.
That's a very good question. The argument (including "+") used to be completely optional, and we did distinguished "no argument" from "empty argument" in some places. But it was confusing (especially when writing policy for such cases) and was removed in R4.0 for VM-originating calls. For dom0-originating calls, policy concern doesn't apply, as those aren't going through it. But for consistency it might be a good idea to always include "+" anyway. > In that > case, dom0 should be fixed to always include the "+". That can be done > in either Python (easy, but requires changing multiple callers) or in > qrexec-client itself. I'd say it's safer to change in Python. qrexec-client normally doesn't parse the command it sends, and changing the command there may lead to some unintended side effects or bugs. But also changing there would make it quite hard to make some exception if turned out necessary. On the Python side, it isn't that many places - one in core-admin, one in core-admin-client and one in core-qrexec. Plus a few in various tests. There are also not that many manual qrexec-client calls, I see them in app-linux-input-proxy and gui-daemon. Anyway, technically this is an API change and as such I'd avoid doing it as R4.2 update. Linux agent should have no issue with this, but other implementations may. For example I see qubes-mirage-firewall is looking for "QUBESRPC qubes.SetDateTime dom0" explicitly: https://github.com/mirage/qubes-mirage-firewall/blob/main/command.ml#L25 > Also, should socket-based services receive what was actually sent > ("qubes.Service") or what was used for lookup ("qubes.Service+")? The > same goes for executable services and the QREXEC_SERVICE_FULL_NAME > environment variable. Right now I fix up QREXEC_SERVICE_FULL_NAME but > not the metadata passed to socket-based services. I'd say socket-based services should receive what was actually sent. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQiUIACgkQ24/THMrX 1yynWQf/QpvzpZ3kCiC1nMidobCjAY/rhtrramEpAuCpceEB7JxHj9vAfnJlify8 xag7PgRiIIZ31+eKxZrYfoW/QBOPiX9tU3/bhtUocjXqS6l0UDiSIA9UMDDqAl0w UJainDUIdzRtH/EPXWjcr48FM3jZmKQPWOAmXteNZfWcmYWH6KtwEaHkyxZ2lLM0 zLcDnWrEykS8DbZpTbClxQ8S4vq8BcYKH1ULMAurmNE3sToJC858Sf4bp8QPvfLN GU2ndsSMUsiHB/1mc7cazjD4DPTqpmy+Od98Cndd08JMpoLPZ6dqqwLh5C8hTQ/W FcDghMPqLIutq4p35O2x2cqE13kOGQ== =MM1I -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZhCJQgWWtKihPusv%40mail-itl.
