-
Notifications
You must be signed in to change notification settings - Fork 223
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
WIP: Add binary shims #553
base: main
Are you sure you want to change the base?
Conversation
Build failed.
|
Using the technique of your sudo wrapper, I tried
|
Loosely based off containers/toolbox#145 Doesn't work with sudo and hard coded shims in the docker container. Pending better UIX with containers/toolbox#553 Signed-off-by: anthr76 <[email protected]>
Is there any update to this PR? |
7ca9a72
to
64a4354
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
Let's see if I can rebase this pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should turn host-wrapper
and sudo-wrapper
into private toolbox(1)
commands? The flatpak-spawn --host
forwarding can benefit from shared code.
|
||
# Shims are located under /usr/libexec/toolbox; the list should not include | ||
# "host-runner" and "sudo" | ||
shims=$(ls /usr/libexec/toolbox | grep -v "host-runner" | grep -v "sudo") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using a separate sub-directory for the shims? It would remove the need for this filtering. Moreover, if we do want users to place their own shims, then we can't trust them not to overwrite things like host-runner
and sudo
.
executable="sudo $executable" | ||
fi | ||
|
||
exec flatpak-spawn --host --watch-bus --forward-fd=1 --forward-fd=2 --directory=$(pwd) --env=TERM=xterm-256color $executable "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to explicitly forward file descriptors 1 and 2? What about 0?
flatpak-spawn(1)
has always forwarded file descriptors 0, 1 and 2. We don't do it explicitly elsewhere either.
executable="sudo $executable" | ||
fi | ||
|
||
exec flatpak-spawn --host --watch-bus --forward-fd=1 --forward-fd=2 --directory=$(pwd) --env=TERM=xterm-256color $executable "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't hard code TERM
. Instead: --env=TERM=$TERM
:)
Also, shouldn't we forward all the other environment variables that we usually do?
64a4354
to
f534ed4
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
f534ed4
to
e640e56
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
e640e56
to
39d4774
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
39d4774
to
546c23b
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
546c23b
to
ed7f137
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
ed7f137
to
267184d
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
267184d
to
8df0914
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
8df0914
to
c531e0e
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
@@ -1,5 +1,9 @@ | |||
# shellcheck shell=sh | |||
|
|||
# Toolbox provides shim binaries for executing commands on the host from inside | |||
# of a toolbox container | |||
export PATH="/usr/libexec/toolbox:$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we really do this unconditionally for both hosts and containers? I think this should ideally happen only for Toolbx containers, not even generic Podman containers. Or did I misunderstand something?
c531e0e
to
49ac68e
Compare
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
e9be361
to
86f76e2
Compare
'host-runner' is a shell script meant to be symlinked against to execute commands on the host from inside of an OCI container. It makes use of 'flatpak-spawn' with it's option --host that takes care of the plumbing from a container to the host. The command itself can not be run as root because it relies on session bus, so instead the command, that is to be executed on the host, needs to be prepended with "sudo <sudo-options>" manually. 'sudo' is a shell script that is meant to be used before /bin/sudo to make it possible to run commands on the host from inside of a container with "sudo" prefixed. It checks first if the command, that is to be run with sudo, is to be run on the host by checking if it is a symlink to /usr/libexec/toolbox/host-runner. If it is not, it is executed normally with /bin/sudo. Both of these files should be put in /usr/libexec/toolbox which will make them available in /run/host/usr/libexec/toolbox in toolbox containers. Thanks to that there's no need to recreate already existing containers because those should have the host /usr already available.
…zation In previous commit the two files, 'host-runner' and 'sudo', were added. This commit adds all the necessary plumbing to make them available in already existing containers and in the new ones. Preparation is done by the 'toolbox init-container' command (the containers' entry-point) by creating symlinks in /usr/libexec/toolbox pointing to the two files under /run/host/usr/libexec/toolbox. If the /usr/libexec/toolbox directory does not exist, it gets created. The final touch is done by /etc/profile.d/toolbox.sh that was previously only used to printing welcome messages. It puts /usr/libexec/toolbox at the beginning of the PATH variable and exports it.
This command is meant to be used in toolbox containers and will be disabled on the host. The created binaries are put in /usr/libexec/toolbox/. The command utilizes the redirectPath function in cmd/initContainer.go.
86f76e2
to
9efa954
Compare
Build failed. ❌ unit-test FAILURE in 9m 42s |
executable="sudo $executable" | ||
fi | ||
|
||
exec flatpak-spawn --host --watch-bus --forward-fd=1 --forward-fd=2 --directory=$(pwd) --env=TERM=xterm-256color $executable "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need the --directory=$(pwd)
because flatpak-spawn(1)
has been retaining the current working directory since before the --directory
option became a thing.
executable="sudo $executable" | ||
fi | ||
|
||
exec flatpak-spawn --host --watch-bus --forward-fd=1 --forward-fd=2 --directory=$(pwd) --env=TERM=xterm-256color $executable "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious about the use of --watch-bus
. It's not wrong, but given that flatpak-spawn(1)
always forwards signals, I am curious if you came across a scenario where the container-side shim would cleanly exit without signals leaving the host-side running. I am trying to understand if we should use --watch-bus
more widely.
This PR adds support for creating binary shims in toolbox containers for binaries available on the host. This was heavily inspired by code snippets in #145. There's also very basic support for running the shim binaries with
sudo
.Closes #145