-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Apr 05, 2024 at 08:25:57PM -0400, Demi Marie Obenour wrote:
> 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 "+"?
I mean changing how dom0 makes calls.
> > > 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.
This also should IMO include the name as was sent to the qrexec agent.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQmAgACgkQ24/THMrX
1yw9fAf/TttfORQja9JZvDE0HELVhWDNKf3ZBRIZ8Q8DJJT9p9AM5/A/2Ifp20k7
csQ43n5YbN03b7Y7wkhJFgHpL3WYiGH94gg7hqr7L8U4jba7Q3Rn1C7KhMdT/iou
fRQCwmGHgh6UJiwPjlhnTU+Jdjv8PYhd4SmPcu7G/zlHOS1Ukim6W2XtfYe8efgP
zMOwGB3pjCaZMyZKWj+QTP56IBGzaHSwsBJcmF3Ng27Z84iu2I3+b6zPucm52Ab+
oPPiW3w9ABDDZ00Wqydhf+TF3zHUMRqxCM9oYdPFGZbcEqMAOvG9xvq2myvHGVQY
xL6rFzIlwnFDSkn6ZxwNZ6j4rFXBtA==
=fDP4
-----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/ZhCYCDxD9o3-X5Zx%40mail-itl.
