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

Always allow app to inherit redirected fds from flatpak-run(1) #5626

Merged
merged 2 commits into from Feb 13, 2024

Conversation

smcv
Copy link
Collaborator

@smcv smcv commented Dec 13, 2023

  • Always allow app to inherit redirected fds from flatpak-run(1)

    As noticed on Limit the usage of WAYLAND_SOCKET to an opt-in feature #5615, under normal circumstances, flatpak-run(1) replaces itself with the bwrap process via execve(), and does not close any fds that it might have inherited from its parent. This allows for patterns like:

      flatpak run com.example.App --in-fd=3 --out-fd=5 3<foo 5>bar
    

    However, using execve() is annoying when trying to analyze code coverage, because the coverage instrumentation does not get the opportunity to write out its data during exit, so it is possible to set FLATPAK_TEST_COVERAGE=1 to make flatpak run the app as a child process and wait for it. This puts us on the code path normally used for apps launched in the background by flatpak_installation_launch_full(), which don't inherit arbitrary fds from their parent.

    Detect this situation and use a different child setup function, avoiding closing fds that we were meant to inherit.

    Fixes: 88a928e "run: Avoid execve() when measuring test coverage"

  • test-run.sh: Assert that fd redirections pass through into the app

    Before the previous commit, this would normally work, but would fail if we had FLATPAK_TEST_COVERAGE=1 in the environment.

@smcv smcv added bug cli Issues involving the flatpak command ready-for-review labels Dec 13, 2023
@swick
Copy link
Contributor

swick commented Dec 13, 2023

LGTM

@smcv
Copy link
Collaborator Author

smcv commented Dec 14, 2023

Since this was written by a maintainer and has had a positive review from a non-maintainer, I'll merge it in a few days unless another maintainer objects.

Copy link
Member

@GeorgesStavracas GeorgesStavracas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

As noticed on flatpak#5615, under normal circumstances, flatpak-run(1)
replaces itself with the bwrap process via execve(), and does not
close any fds that it might have inherited from its parent. This
allows for patterns like:

    flatpak run com.example.App --in-fd=3 --out-fd=5 3<foo 5>bar

However, using execve() is annoying when trying to analyze code
coverage, because the coverage instrumentation does not get the
opportunity to write out its data during exit, so it is possible to
set FLATPAK_TEST_COVERAGE=1 to make flatpak run the app as a child
process and wait for it. This puts us on the code path normally used
for apps launched in the background by flatpak_installation_launch_full(),
which *don't* inherit arbitrary fds from their parent.

Detect this situation and use a different child setup function,
avoiding closing fds that we were meant to inherit.

Fixes: 88a928e "run: Avoid execve() when measuring test coverage"
Signed-off-by: Simon McVittie <[email protected]>
Before the previous commit, this would normally work, but would fail if
we had FLATPAK_TEST_COVERAGE=1 in the environment.

Signed-off-by: Simon McVittie <[email protected]>
@smcv smcv merged commit 3a297d8 into flatpak:main Feb 13, 2024
6 checks passed
@smcv smcv deleted the fd-inheritance branch February 13, 2024 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug cli Issues involving the flatpak command ready-for-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants