-
Notifications
You must be signed in to change notification settings - Fork 198
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
[v0.58] backport my networking fixes #1954
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the netns program fails to configure the netns or we fail for any other reason during the setup we must make sure to remove the netns mount again. Without it the next command sees the existing mount and thinks the netns was setup correctly but than later fails during the custom resolv.conf mount because the resolv.conf source file was never created. For future we should consider adding checks due ensure pasta/slirp4netns is still running when we access the netns to make it more fault tolerant. The reason this is a common problem is that on boot pasta can likely fail if it was started before the networking was fully configured (i.e. no default route). Fixes containers/podman#22168 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add a function to read a pidfile, this helps to avoid some duplication. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We have little to no control over what happens tot he slirp4netns/pasta process after we started it. It could crash or get killed then we end up in state where we think networking works when it doesn't. To fix this each time we access the rootless-netns we should also make to program is still running, if it is not try to recover by starting it again. This ensures that we are much more fault tolerant. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The IsRootless() check is dangerous in a sense that it may not do what you think it does. It also returns true even when podman is run as root and not in the podman userns but as part of a different userns. Could be a other container manager that configured the userns. This results in us doing the rootless-netns logic even when we should not need to. To fix this we now check for the _CONTAINERS_USERNS_CONFIGURED env var to make sure we are not re-exe'ed. This is what we actually care about. This is a regression compared to podman 4.X, because the code was moved into c/common the IsRootless() check was changed to the c/storage version which has the userns special case. Fixes containers/podman#22218 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
While this is a none issue normally because we run in a unprivileged userns we cannot modify the host mounts in any way. However in case where the rootless netns logic might be executed from a non userns context we might change the mount tree if the mounts are shared which is the systemd default. While this should never happen let's make sure we never mess up the system by accident in case there are more bugs and explicitly make our mount tree private. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This here just logs unnecessary errors in case there is an error during the Run() call (podman unshare --rootless-netns). runInner() will already call cleanup on errors if it created a new netns so we only need to cleanup when there is no error. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is good to prevent any leaks but more important here there is a bug because we cache the last assigned ip. However when a network is removed the recreated with a different LeaseRange that ip might be very well outside the expected range and the logic seems to handle this correctly. I could fix it there but deleting the full bucket seems best as it avoid other issues and leaking the bucket forever. Fixes containers/podman#22034 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
LGTM |
/lgtm |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport #1946 and #1945