Fix --userns=ns:<path> conflicting with runc 1.1.11+ #27239

Honny1 · 2025-10-06T17:48:58Z

Remove dummy UID/GID mappings added when joining existing user namespaces, which runc 1.1.11+ rejects as conflicting.

Does this PR introduce a user-facing change?

--userns=ns:<path> now works correctly with runc 1.1.11+ by not adding dummy UID/GID mappings when joining existing user namespaces (#27148)

Honny1 · 2025-10-06T17:50:25Z

cc @bpoldrack @giuseppe @Luap99 @mheon

mheon · 2025-10-06T18:56:44Z

Does this break on earlier runc versions?

Honny1 · 2025-10-06T19:00:23Z

Does this break on earlier runc versions?

I think so. However, I'm not sure how to check the runc version.

Honny1 · 2025-10-06T19:03:26Z

Also, I'm not sure how old a runc version we support.

mheon · 2025-10-06T20:32:41Z

We don't have an official minimum supported version. We might want to figure that out, if we're going to break older runc. @kolyshkin Do you know when runc stopped needing this hack?

ninja-quokka · 2025-10-06T20:49:29Z

The first release with this change of behavior runc v1.1.11 was released at the beginning of 2024, all I can find documented about a minimum supported version of runc in Podman is this in our installation docs so it is somewhat softly defined as 1.0.0-rc4 or 1.0.1.

The safest option could be to make this conditional and drop support for runc <v1.1.11 in our 6.0 release.

A potentially brittle method to check the version the user is running could be parsing the output of runc --version which should be semver:
https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/main.go#L43

https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/main.go#L26-L29

https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/VERSION#L1C1-L1C15

kolyshkin · 2025-10-06T20:57:54Z

We don't have an official minimum supported version. We might want to figure that out, if we're going to break older runc. @kolyshkin Do you know when runc stopped needing this hack?

This was merged in runc 1.2.0-rc.1 (Apr 3, 2024, with the final 1.2.0 released in Oct 2024), and was backported to runc 1.1 branch (included in runc v1.1.11, Jan 1, 2024).

From what I see RHEL8 uses runc v1.1.12, and that's the oldest version I can find.

Honny1 · 2025-10-07T08:59:43Z

The safest option could be to make this conditional and drop support for runc <v1.1.11 in our 6.0 release.

I agree that this is probably the safest way.

A potentially brittle method to check the version the user is running could be parsing the output of runc --version which should be semver: https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/main.go#L43

https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/main.go#L26-L29

https://github.com/opencontainers/runc/blob/bc432ce88cf81ac632a8247e85e8cdce6deca105/VERSION#L1C1-L1C15

Getting the runtime version is not trivial. Podman has a function that gets information about the container runtime, but this function causes cyclic imports. Blindly calling runc --version each time is not the best idea, because Podman can use runc from a different path or have some other non-standard configuration for debugging purposes. I suspect that getting the path to runc would also lead to a cyclic import. If anyone knows a trick that would solve this versioning issue, please let me know.

Luap99 · 2025-10-07T09:53:35Z

test/system/170-run-userns.bats

+
+# bats test_tags=ci:parallel
+@test "podman --userns=ns:<path> join existing user namespace" {
+    skip_if_not_rootless


This should work fine rootless I belive?

Luap99 · 2025-10-07T09:56:16Z

test/system/170-run-userns.bats

+    skip_if_not_rootless
+    # Test for issue #27148: --userns=ns:<path> should not add dummy mappings
+
+    local cname="userns_source_$(random_string 8)"


do not use random_string for resource names, always use safename

Luap99 · 2025-10-07T09:56:43Z

test/system/170-run-userns.bats

+    local pid=$output
+    local userns_path="/proc/$pid/ns/user"
+
+    test -e "$userns_path"


that seems unnecessary, podmna run will fail if the path is not valid.

Luap99 · 2025-10-07T10:00:57Z

test/system/170-run-userns.bats

+    run_podman run --rm --userns=ns:$userns_path $IMAGE echo "success"
+    assert "$output" == "success" "Should be able to join existing user namespace"


The echo doesn't actually test that we successfully joined the same userns though. If userns is a NOP

see the test in test/system/195-run-namespaces.bats as example, you should run something like readlink /proc/self/ns/user and then compare that against the podman exec $cname readlink /proc/self/ns/user output to ensure they do in fact use the same userns, we could also compare cat /proc/self/uid_map for good measures

Luap99 · 2025-10-07T10:04:34Z

I am not a fan of version checks, it complicates things and practically good always lie with distros backporting fixes without version number changes.

The way I see it --userns ns: is broken with runc of today so podman of today should work with it so I personally would just go ahead with this, as @kolyshkin mentioned the runc fix is out for well over a year so if people update podman without updating the underlying oci runtime they always can encounter problems.

Remove dummy UID/GID mappings added when joining existing user namespaces, which runc 1.1.11+ rejects as conflicting. RUNC fix: opencontainers/runc#4124 Fixes containers#27148 Signed-off-by: Jan Rodák <[email protected]>

Honny1 · 2025-10-07T14:21:08Z

@Luap99 I have updated the test according to your review.

Luap99

LGTM

ninja-quokka

/LGTM

I will create an issue for updating the runc minimum version.

openshift-ci · 2025-10-07T19:17:19Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Honny1, Luap99, ninja-quokka

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:

~~OWNERS~~ [Luap99]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note labels Oct 6, 2025

Luap99 reviewed Oct 7, 2025

View reviewed changes

Fix --userns=ns:<path> conflicting with runc 1.1.11+

79ecc1d

Remove dummy UID/GID mappings added when joining existing user namespaces, which runc 1.1.11+ rejects as conflicting. RUNC fix: opencontainers/runc#4124 Fixes containers#27148 Signed-off-by: Jan Rodák <[email protected]>

Honny1 force-pushed the fix-mapping-ns branch from 46e3a80 to 79ecc1d Compare October 7, 2025 13:46

Honny1 marked this pull request as ready for review October 7, 2025 14:19

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 7, 2025

Luap99 approved these changes Oct 7, 2025

View reviewed changes

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 7, 2025

ninja-quokka approved these changes Oct 7, 2025

View reviewed changes

openshift-ci bot assigned ninja-quokka Oct 7, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 7, 2025

openshift-merge-bot bot merged commit 7fecff5 into containers:main Oct 7, 2025
81 checks passed

ninja-quokka mentioned this pull request Oct 7, 2025

[DOCS] Podmans minumum supported runc version should be updated #27243

Open

		run_podman run --rm --userns=ns:$userns_path $IMAGE echo "success"
		assert "$output" == "success" "Should be able to join existing user namespace"

Fix --userns=ns:<path> conflicting with runc 1.1.11+ #27239

Fix --userns=ns:<path> conflicting with runc 1.1.11+ #27239

Conversation

Honny1 commented Oct 6, 2025

Does this PR introduce a user-facing change?

Uh oh!

Honny1 commented Oct 6, 2025

Uh oh!

mheon commented Oct 6, 2025

Uh oh!

Honny1 commented Oct 6, 2025

Uh oh!

Honny1 commented Oct 6, 2025

Uh oh!

mheon commented Oct 6, 2025

Uh oh!

ninja-quokka commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kolyshkin commented Oct 6, 2025

Uh oh!

Honny1 commented Oct 7, 2025

Uh oh!

Luap99 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

Luap99 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

Luap99 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

Luap99 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

Luap99 commented Oct 7, 2025

Uh oh!

Honny1 commented Oct 7, 2025

Uh oh!

Luap99 left a comment

Choose a reason for hiding this comment

Uh oh!

ninja-quokka left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Oct 7, 2025

Uh oh!

Uh oh!

Uh oh!

ninja-quokka commented Oct 6, 2025 •

edited

Loading