run: block PODMAN_USERNS and --pod #18601
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe 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 |
openshift-ci
bot
added
the
approved
|
Would it make more sense to ignore the env when the pod already has the same userns mode? Consider the case where someone might set it in their bashrc. It would be very annoying to unset the env for all podman run/create commands and you know the pod has already the specified userns mode anyway. |
giuseppe
force-pushed
the
block-PODMAN_USERNS-and---pod
branch
from
74f624e to
471baf7
Compare
I thought about it but I wasn't sure what was better, if blocking or ignoring it; but you made a good point, it will start causing weird errors and failures now, so let's just ignore |
i think this is a good idea. everything else LGTM |
|
/lgtm |
openshift-ci
bot
added
the
do-not-merge/hold
the combination --pod and --userns is already blocked. Ignore the PODMAN_USERNS variable when a pod is used, since it would cause to create a new user namespace for the container. Ideally a container should be able to do that, but its user namespace must be a child of the pod user namespace, not a sibling. Since nested user namespaces are not allowed in the OCI runtime specs, disallow this case, since the end result is just confusing for the user. Closes: containers#18580 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
force-pushed
the
block-PODMAN_USERNS-and---pod
branch
from
471baf7 to
192ad70
Compare
sure, added a note |
|
/lgtm |
|
LGTM |
openshift-ci
bot
removed
the
do-not-merge/hold
github-actions
bot
added
the
locked - please file new issue/PR
the combination --pod and --userns is already blocked. The PODMAN_USERNS environment variable instead circumvents the check. Make sure the combination is also blocked, otherwise we end up creating containers in a different user namespace than their pod.
Ideally a container should be able to do that, but its user namespace must be a child of the pod user namespace, not a sibling. Since nested user namespaces are not allowed in the OCI runtime specs, disallow this case, since the end result is just confusing for the user.
Closes: #18580
Does this PR introduce a user-facing change?