-
Notifications
You must be signed in to change notification settings - Fork 321
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
exec: crun: setns(pid=87793, CLONE_SOMETHING): Operation not permitted: OCI permission denied #1264
Comments
I am pretty sure the first one was a variant of containers/podman#17903. New userns so it was no longer able to join the existing user namespace in exec. The second one is something different. |
A friendly reminder that this issue had no activity for 30 days. |
Here it is again, today, f37 remote root:
|
@giuseppe PTAL, AFAIK userns=keep-id as root is just a NOP so it should be no different then a normal podman run without userns. |
with root we still create a new user namespace but we map the entire IDs space. |
Another one, f37 root remote. @giuseppe thank you for your answer, do you think you could code up a fix please? |
A friendly reminder that this issue had no activity for 30 days. |
@giuseppe were you able to work on this one? |
I'll take another look, last time I looked at this issue I have not managed to reproduce locally |
Here's the full list:
All of them in containers/podman#17831, because the flake seems to pass on retry. I have not been hammering on that PR as much in the past month, which is one reason why we haven't seen it in the last month. |
I can't recall why the original code was setting the user namespace separately, probably it was an issue specific to an old kernel. I've tried with the current kernel and it works fine to do all the setns() in one shoot so let's simplify the code and avoid an EPERM error on the second setns() when using a user namespace. Closes: containers#1264 Signed-off-by: Giuseppe Scrivano <[email protected]>
I can't recall why the original code was setting the user namespace separately, probably it was an issue specific to an old kernel. I've tried with the current kernel and it works fine to do all the setns() in one shoot so let's simplify the code and avoid an EPERM error on the second setns() when using a user namespace. This caused an issue when the PID 1 didn't execve yet the container process, and joining the user namespace first would cause the user to look access to the container PID 1 namespaces. Closes: containers#1264 Signed-off-by: Giuseppe Scrivano <[email protected]>
opened a PR: #1265 |
This caused an issue when the PID 1 didn't execve yet the container process, and joining the user namespace first would cause the user to look access to the container PID 1 namespaces. When running with enough permissions, setns() will allow to join all the namespaces in one shoot, so let's use it. On any error, attempt the fallback mechanism to join each namespace separately. Closes: containers#1264 Signed-off-by: Giuseppe Scrivano <[email protected]>
and
Only two, both in my no-flake-retries PR. root & rootless, local & remote, f38 and rawhide. Different tests, the common factor is that both tests involve
userns
.podman create --userns=keep-id + podman exec - correct names of user and group
[It] podman run --userns=keep-id can add users
The text was updated successfully, but these errors were encountered: