-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Slirp: Remove for Podman6 #27338
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
Slirp: Remove for Podman6 #27338
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lsm5 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3f540c7 to
846a13c
Compare
846a13c to
218b398
Compare
|
[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore. |
1 similar comment
|
[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore. |
583764c to
d7744ec
Compare
|
Yeah, that sounds like a genuine problem on the podman side: |
d7744ec to
a55c778
Compare
a55c778 to
f36cb63
Compare
f36cb63 to
2e7738c
Compare
d9d63e6 to
42f95ad
Compare
b0d486b to
65538e9
Compare
When NetMode.IsPasta() is true but pastaResult is nil (which can happen during container setup failures or in certain edge cases), accessing c.pastaResult.IPAddresses causes a panic. Add a nil check for c.pastaResult before accessing its fields, matching the pattern used elsewhere in the codebase. Fixes rootless test failures in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
When NetMode.IsPasta() is true but pastaResult is nil (which can happen during container setup failures or in certain edge cases), accessing c.pastaResult.IPAddresses causes a panic. Add a nil check for c.pastaResult before accessing its fields, matching the pattern used elsewhere in the codebase. Fixes rootless test failures in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
77bc1b3 to
dce5c56
Compare
dce5c56 to
767a9af
Compare
When NetMode.IsPasta() is true but pastaResult is nil (which can happen during container setup failures or in certain edge cases), accessing c.pastaResult.IPAddresses causes a panic. Add a nil check for c.pastaResult before accessing its fields, matching the pattern used elsewhere in the codebase. Fixes rootless test failures in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
When NetMode.IsPasta() is true but pastaResult is nil (which can happen during container setup failures or in certain edge cases), accessing c.pastaResult.IPAddresses causes a panic. Add a nil check for c.pastaResult before accessing its fields, matching the pattern used elsewhere in the codebase. Fixes rootless test failures in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
767a9af to
9815be9
Compare
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
When NetMode.IsPasta() is true but pastaResult is nil (which can happen during container setup failures or in certain edge cases), accessing c.pastaResult.IPAddresses causes a panic. Add a nil check for c.pastaResult before accessing its fields, matching the pattern used elsewhere in the codebase. Fixes rootless test failures in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
…essPortMappingViaRLK When PostConfigureNetNS is true, the network namespace is configured after container start (in completeNetworkSetup). In this case, the rootlessPortSyncR/W pipes were never created, causing two issues: 1. Nil pointer dereference when CloseQuiet tried to close the nil pipe 2. Port forwarding failures because nil was passed to the vendor SetupRootlessPortMappingViaRLK function, which expects a valid pipe Fix by: - Always creating the pipes when they don't exist (checked via nil) - Only defer-closing them when !PostConfigureNetNS to avoid double-close This matches the pattern from the old setupSlirp4netns code which checked for nil before deferring the close. Also removes the obsolete test/compose/slirp4netns_opts/ test directory which was testing slirp4netns network mode that no longer exists. Fixes test failures in PR containers#27338: - sys remote: "podman networking: port with --userns=keep-id for rootless" - compose_v2: "slirp4netns_opts - up" - int podman: "podman kube play" port publishing tests Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
9815be9 to
7fb9274
Compare
When PostConfigureNetNS is true (which happens with --userns=keep-id or other user namespace options), the network namespace is configured after container start. In this case, the rootlessport sync pipes need special handling: 1. The pipes must be created BEFORE conmon starts (not during network setup) 2. The write end must be leaked to conmon via ExtraFiles 3. When conmon exits, closing the write end signals rootlessport to exit The previous fix in commit 7fb9274 only handled pipe creation during network setup, but didn't account for the PostConfigureNetNS flow where pipes need to be created earlier and passed to conmon. This fix: - Creates rootlessPortSync pipes in oci_conmon_common.go when PostConfigureNetNS=true and ports exist - Leaks the write end to conmon so it stays open for container lifetime - In setupRootlessPortMappingViaRLK, checks if pipes already exist (from conmon code) before creating new ones - Always closes the read end in parent after passing to rootlessport child Fixes the "port with --userns=keep-id" test failure in PR containers#27338. Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
This commit fixes rootless port forwarding by ensuring rootlessport
sync pipes are created at the correct time in the container lifecycle.
The core issue was that pipes were created AFTER network setup instead
of BEFORE, causing the rootlessport process to use different pipe file
descriptors than those leaked to conmon.
Changes:
1. container_internal_linux.go (prepare function):
Create rootlessport sync pipes BEFORE calling createNetNS() for
normal containers (!PostConfigureNetNS). This ensures the pipes
exist when setupRootlessPortMappingViaRLK is called during network
configuration.
2. oci_conmon_common.go (createOCIContainer function):
- For PostConfigureNetNS containers: Create pipes here since
network setup happens after container start
- For normal containers: Just leak the existing pipes created in
prepare() instead of creating new ones
3. networking_slirp4netns.go (setupRootlessPortMappingViaRLK):
- Check if pipes already exist before creating new ones
- Always close the read end after spawning rootlessport process
- Add debug logging to trace pipe lifecycle
4. networking_linux.go (configureNetNS):
Add debug logging to help trace port forwarding setup
Testing:
- Port forwarding now works correctly for normal rootless containers
- rootlessport process successfully starts and listens on the socket
- Verified with: nc -w 1 127.0.0.1 <port> && echo "Connection successful"
Known issues not addressed by this commit:
- --userns=keep-id containers have pre-existing permission denied errors
preventing any binary execution (exists on main branch)
- NetworkSettings.SandboxKey may be empty for PostConfigureNetNS
containers due to cleanup timing
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
|
obsoleted by #27828 |
Does this PR introduce a user-facing change?