Support TCP socket qrexec services

[marmarek]

How to file a helpful issue

The problem you're addressing (if any)

When using existing service via qrexec, some do not support UNIX sockets, only TCP. One example is qubes.UpdatesProxy, which uses socat right now. This approach mostly works (but sometimes cause issues, like when socat update changes it behavior), but has significant connection overhead.

The solution you'd like

Currently, service files in /etc/qubes-rpc can either be executable (or a symlink to an executable), or an UNIX socket (or a symlink to a UNIX socket). TCP target can be configured with a symlink too, using bash-inspired syntax /dev/tcp/host/port. Qrexec would readlink the file and if it points at the special /dev/tcp/... target, parse it as host + port and open a TCP connection. Then, proceed similar to the existing socket service.

• Add support for /dev/tcp/host/port target. The "host" part definitely needs to support IPv4 addresses. But IPv6 addresses or host names to be resolved might be a good idea too.
• Document at https://www.qubes-os.org/doc/qrexec-socket-services/ and possibly mention at https://www.qubes-os.org/doc/qrexec/ (currently it doesn't have link to socket services doc at all...)
• Write unit tests

The value to a user, and who that user might be

Together with #9036, it will allow services like qubes.UpdatesProxy work without extra process in the middle. This would avoid issues like #9025

[DemiMarie]

If the host and port are omitted, could they be taken from the service arguments?

[marmarek]

That's a very good question. It would allow socat-less qubes.ConnectTCP. So, maybe yes?

[DemiMarie]

I think that is a good idea.