Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending SIGUSR1 to a qrexec program doesn't work if the remote side has sent EOF #9183

Closed
DemiMarie opened this issue May 1, 2024 · 0 comments · Fixed by QubesOS/qubes-core-qrexec#157
Labels
affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. C: core diagnosed Technical diagnosis has been performed (see issue comments). 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
Copy link

How to file a helpful issue

Qubes OS release

R4.2 but the problem is almost certainly older than R4.1.

Brief summary

Sending SIGUSR1 to a qrexec program (anything using libqrexec/process_io.c:process_io()) doesn't work if the remote side has sent EOF already.

Steps to reproduce

Something like this (untested) should work:

  • Client: qrexec-client-vm VMNAME SERVICE< /dev/null

  • /etc/qubes-rpc/SERVICE:

    #!/bin/bash --
    sleep 10
    kill -USR1 "$PPID"
    sleep 10
    echo This is a test >&0

Expected behavior

This is a test displayed on the client's stdout

Actual behavior

The data is discarded.

@DemiMarie DemiMarie added T: bug C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. labels May 1, 2024
@andrewdavidwong andrewdavidwong added the needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. label May 1, 2024
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue May 1, 2024
Just shut it down for writing, and save it so that it can later be used
for reading.

This also ensures deterministic behavior when --use-stdin-socket is
used.  Previously, the socket would be shut down for reading or writing
but not both, depending on whether reading or writing stopped first.
This could be quite confusing for callers.  Instead, always shut down
the socket for both reading and writing, guaranteeing deterministic
behavior.

Fixes: a3bbcb5 ("Prefer close() to shutdown()")
Fixes: QubesOS/qubes-issues#9183
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue May 2, 2024
Just shut it down for writing, and save it so that it can later be used
for reading.

This also ensures deterministic behavior when --use-stdin-socket is
used.  Previously, the socket would be shut down for reading or writing
but not both, depending on whether reading or writing stopped first.
This could be quite confusing for callers.  Instead, always shut down
the socket for both reading and writing, guaranteeing deterministic
behavior.

Fixes: a3bbcb5 ("Prefer close() to shutdown()")
Fixes: QubesOS/qubes-issues#9183
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue May 2, 2024
Just shut it down for writing, and save it so that it can later be used
for reading.

This also ensures deterministic behavior when --use-stdin-socket is
used.  Previously, the socket would be shut down for reading or writing
but not both, depending on whether reading or writing stopped first.
This could be quite confusing for callers.  Instead, always shut down
the socket for both reading and writing, guaranteeing deterministic
behavior.

This partially reverts a3bbcb5 ("Prefer close() to shutdown()"):
the change to use close() is reverted, but the substantial
simplification of the code is not.

Fixes: a3bbcb5 ("Prefer close() to shutdown()")
Fixes: QubesOS/qubes-issues#9183
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue May 2, 2024
Just shut it down for writing, and save it so that it can later be used
for reading.

This also ensures deterministic behavior when --use-stdin-socket is
used.  Previously, the socket would be shut down for reading or writing
but not both, depending on whether reading or writing stopped first.
This could be quite confusing for callers.  Instead, always shut down
the socket for both reading and writing, guaranteeing deterministic
behavior.

This partially reverts a3bbcb5 ("Prefer close() to shutdown()"):
the change to use close() is reverted, but the substantial
simplification of the code is not.

Fixes: a3bbcb5 ("Prefer close() to shutdown()")
Fixes: QubesOS/qubes-issues#9183
@andrewdavidwong andrewdavidwong added diagnosed Technical diagnosis has been performed (see issue comments). pr submitted A pull request has been submitted for this issue. and removed needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. labels May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. C: core diagnosed Technical diagnosis has been performed (see issue comments). 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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants