Always send EOF on streams #164
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #164 +/- ##
==========================================
+ Coverage 77.93% 77.99% +0.06%
==========================================
Files 54 54
Lines 9618 9636 +18
==========================================
+ Hits 7496 7516 +20
+ Misses 2122 2120 -2 ☔ View full report in Codecov by Sentry. |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024061414-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024052808-4.3&flavor=update
Failed tests13 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/101100#dependencies 38 fixed
Unstable tests
|
Previously, this was not guaranteed to happen if the process was exiting, and MSG_DATA_STDERR would not be sent for socket services at all. There is still a case where an empty MSG_DATA_STDOUT might not be sent. Fixes: QubesOS/qubes-issues#9142 Fixes: QubesOS/qubes-issues#9248
Previously, if a service with exit-on-client-eof=true received EOF on stdin while stdout was still open, no EOF would be sent on stdout. This is a (currently harmless) violation of the qrexec protocol. Fix this by sending an empty MSG_DATA_STDOUT to indicate EOF on stdout. Fixes: QubesOS/qubes-issues#9429
This is expected by the protocol.
MSG_DATA_EXIT_CODE is ignored by services, and clients always have stderr_fd == -1.
Previously, this was not guaranteed to happen if the process was exiting, and neither dom0 nor socket services would send a
MSG_DATA_STDERR.Fixes: QubesOS/qubes-issues#9142
Fixes: QubesOS/qubes-issues#9248
Fixes: QubesOS/qubes-issues#9249