-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, Apr 06, 2024 at 01:29:06AM +0200, Marek Marczykowski-Górecki wrote: > 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.
I'm inclined to agree. > > 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. Changing it in qrexec-client turned out to be quite easy, but it also raises concerns about the same command being parsed different ways (due to e.g. version skew), and so I decided to not go that route. It also indeed makes an exception impossible to add without some sort of out-of-band signalling, such as a new command-line option. > 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 By "this", do you mean changing the API calls made by dom0 to include the "+", or changing the way the Linux agent interprets calls that do not include the "+"? > > 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. That makes sense, and is actually simpler to implement. What about QREXEC_SERVICE_FULL_NAME? That's the analog for executable services. By analogy to socket-based services, it makes sense to pass what was actually sent here too, but I currently add a trailing "+" if none is present. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYQlpUACgkQsoi1X/+c IsHoUg/7B2ZBotLyXRL6teNFabpvDYmprficx8aYURWS/vUIyN/xuCdHBipHFeXi x9Dl5vsPrrL/+2FAaTGd0dfe8/wc4b7nsev04ynUYTUZ0w5wTnLgA5yABrpct9Hl TBHoIx6AfWrEZ6RzdPQaCnkjDveuTTSrblpRJ2AKi5CA1BJaQg3HHNL3+75akg8R KFk0xFyVAcHyeF54FzCokdUcXbecY7LqXvZ0c1LttcAcn1vnBFPuwcUxFc5stIJk cUOOmOcOAj+NRnPQyYfnbkDNTLVxuvCMmkyrmPJbiVoruHp9NRXIObpG+lI21bHs rj6eeYM+XakP7wYc38uJC3UmevlPkj2+ctyZc9h9cfLVs0wL4N2uImHPlnvQKTmR Fz8jCu68D3EHkcXZhqtc8PcVoSq8iR8wgzr4SoMIAlsZTDX0ZgbdGhxuIBSSvtb0 rr0ji8DaT5hwVUERWLFZChX9fZdjtA2KSkT4tTQHlYdenI+9L+jc0LT4fcZVbj2i gvBRV6NpiCTTQnuUOxsApNF8Qe7fjMH+Y0BQPfRxdthBlNcIMcgV6qyTwsExfeH1 8DsgqfuA0H++Cs9YeToV5yhPWvYvuQPiSzp9WLZLMXN4aO5gPhoun4JS0J06J0TC 8Fy6pRAcwktir6y+69g68sKLyZz8iaXKi8xhnF5qxcM02U63mRc= =URTR -----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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZhCWlf16nAbrO8aZ%40itl-email.
