Socket-based services should support exiting when remote shuts down write end #9176
Assignees
Labels
C: core
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
pr submitted
A pull request has been submitted for this issue.
Comments
DemiMarie
added
T: enhancement
C: core
P: default
Does it make sense to create a lint tool for rpc-config to detect these problems at will instead of at runtime? The tool qubes-policy-lint is a wrapper of If it is possible, should I create another issue about this? |
|
Please do create another issue. The format is a strict subset of TOML. TOML allows lots of syntax that the configuration parser will reject. However, if the configuration parser accepts a file, it should interpret the file according to the TOML specification. If you can get the configuration parser to accept a file and parse it dfferently than the TOML specification requires, please report it as a bug. |
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 2, 2024
This adds two new boolean service configuration options: - exit-on-stdout-eof: exit when the socket service shuts down its output stream for writing. - exit-on-stdin-eof: exit when the client sends EOF. To avoid compatibility problems, global variables are used to pass this information from the configuration parser to the I/O code. In the future, there should be a better way to pass this information, so global variables are used right now. Fortunately, the configuration parser only runs once in the life of any process right now, so this commit adds assertions to check this. Qubes OS ships with assertions enabled, so any violation of this rule will be detected. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 4, 2024
This adds two new boolean service configuration options: - exit-on-stdout-eof: exit when the socket service shuts down its output stream for writing. - exit-on-stdin-eof: exit when the client sends EOF. To avoid compatibility problems, global variables are used to pass this information from the configuration parser to the I/O code. In the future, there should be a better way to pass this information, so global variables are used right now. Fortunately, the configuration parser only runs once in the life of any process right now, so this commit adds assertions to check this. Qubes OS ships with assertions enabled, so any violation of this rule will be detected. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 4, 2024
This adds two new boolean service configuration options: - exit-on-stdout-eof: exit when the socket service shuts down its output stream for writing. - exit-on-stdin-eof: exit when the client sends EOF. To avoid compatibility problems, global variables are used to pass this information from the configuration parser to the I/O code. In the future, there should be a better way to pass this information, but this is not possible without more extensive changes. Fortunately, the configuration parser only runs once in the life of any process right now, so this commit adds assertions to check this. Qubes OS ships with assertions enabled, so any violation of this rule will be detected. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 4, 2024
This adds two new boolean service configuration options: - exit-on-stdout-eof: exit when the socket service shuts down its output stream for writing. - exit-on-stdin-eof: exit when the client sends EOF. To avoid compatibility problems, global variables are used to pass this information from the configuration parser to the I/O code. In the future, there should be a better way to pass this information, but this is not possible without more extensive changes. Fortunately, the configuration parser only runs once in the life of any process right now, so this commit adds assertions to check this. Qubes OS ships with assertions enabled, so any violation of this rule will be detected. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 5, 2024
This adds two new boolean service configuration options: - exit-on-stdout-eof: exit when the socket service shuts down its output stream for writing. - exit-on-stdin-eof: exit when the client sends EOF. The information is passed through an extended qrexec_parsed_command struct. New functions are added that avoid the executables having to access members that are private to libqrexec. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
May 5, 2024
This adds two new boolean service configuration options: - exit-on-service-eof: exit when the socket service shuts down its output stream for writing. - exit-on-client-eof: exit when the client shuts down its output stream for writing. The information is passed through an extended qrexec_parsed_command struct. New functions are added that avoid the executables having to access members that are private to libqrexec. The main use of these features is to emulate the old qubes.ConnectTCP and qubes.UpdatesProxy services, which already had this behavior due to the use of socat. These features are only supported for socket-based services, as executable services are more complicated and do not have a use case right now. Currently, if a service exits due to exit-on-stdin-eof, the empty MSG_DATA_STDOUT that indicates EOF is not sent. This is not a problem because qrexec-client-vm interprets MSG_DATA_EXIT_CODE as also indicating EOF on stdout and stderr. Fixes: QubesOS/qubes-issues#9176
This was referenced May 9, 2024
andrewdavidwong
added
the
pr submitted
ben-grande
added a commit
to ben-grande/qubes-core-qrexec
that referenced
this issue
May 11, 2024
ben-grande
added a commit
to ben-grande/qubes-core-qrexec
that referenced
this issue
May 18, 2024
This was referenced Jun 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How to file a helpful issue
The problem you're addressing (if any)
Existing VMs assume that
qubes.UpdatesProxyandqubes.ConnectTCPwill terminate after the server shuts down the write end of its connection. This is currently implemented bysocat, with a useless 0.5s timeout. Native socket-based services would be better, but runs into #9169 with the currentqrexec-client-vmimplementation. #9169 can be fixed by changes toqrexec-client-vmand[email protected], but these changes work around this problem on the client side, rather than restoring the previous server behavior. This means that the new services are incompatible with existing VMs that need to be updated, which is very bad.The solution you'd like
Add a new service configuration directive that causes the service to send
MSG_DATA_EXIT_CODEand terminate when the socket server shuts down the connection for writing, the VM shuts down the connection for reading, or both. These should be controllable separately.Proposed names:
terminate-on-send-eofandterminate-on-recv-eof. Both will be incompatible withforce-user=and executable services.The value to a user, and who that user might be
Users will be able to use a native socket-based service instead of
socatforqubes.ConnectTCPandqubes.UpdatesProxy, without needing a newqrexec-client-vm.Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
terminate-on-send-eof=trueworksterminate-on-recv-eof=trueworksterminate-on-send-eof=trueandterminate-on-recv-eof=trueworksforce-user=and with executable services.The text was updated successfully, but these errors were encountered: