-
Notifications
You must be signed in to change notification settings - Fork 231
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
uid range not allowed #334
Comments
I have the same issue with img v0.5.11. After some testing it seems the issue appears since 0.5.8, which has a lot of changes for a micro version increment: v0.5.7...v0.5.8 |
I also have this issue. It's impeding me for a while now (It prevented me from using img on Debian for a long time (~5 months from now), until I managed to build img from scratch with go 1.13 (A few weeks ago)). I corroborate @shoelzle: It breaks between v0.5.7 (d14bb92) and v0.5.8 (213cd7b). I'm not fluent in Go at all and gdb struggle to debug Go code so I'm struggling a lot to find the root cause. Here is the least hacky prints-based debug that exhibits symptoms of the aforementioned behavior:
Sample output for v0.5.11:
Sample output for v0.5.7:
|
reexec.Init() wasn't called in img's main, while buildkit solver enventually reexec'd in the registered initialization function "docker-untar" This is a quick-and-dirty fix to prevent an unecessary namespace unshare
reexec.Init() wasn't called in img's main, while buildkit solver enventually reexec'd in the registered initialization function "docker-untar" This is a quick-and-dirty fix to prevent an unecessary namespace unshare
I confirm that v0.5.7 never execute Here is a GDB backtrace of img v0.5.11 in the main subprocess (The one being unshared properly, and doing most of the stuff), the part of (part of) the callstack leading to the execution of
From what I understand, the img way to unshare namespaces doesn't play nice with docker's reexec module. The latter, in an init function (one running past the main), reads I pushed a dirty fix at lel-amri@b409d1e (Temporary branch |
@jessfraz Is there a need for changing user namespaces on init functions ? I think I found a clean way to fix this, as long as I unshare past the main. |
Hi @lel-amri , Without modification
With modification:
|
Thanks for testing @GitNico. I'll try to come up with something cleaner, then submit a PR. In the meantime I'll try to maintain a downstream fix on my clone. I'll keep you informed. |
I found the breaking change between v0.5.7 and v0.5.8: buildkit changed the way it extracts archive files:
It "now" ("then", actually) ultimately uses the function untar at https://github.com/moby/moby/blob/e7b5f7dbe98c559b20c0c8c20c0b31a6b197d717/pkg/chrootarchive/archive_unix.go#L22. That confirm that the only way to circumvent the issue is to properly make use of the Docker's reexec module. I tried to come up with a small fix, but the mix of C and Go for process initialization doesn't play nicely. I can either get the namespace unshare or the Docker reexec, but not both. It nearly always ends up in a deadlock during Go runtime initialization. The only way I can think of to fix this issue is to re-implement namespaces unsharing in img. |
Hey guys, sorry for the delay, I had a lot to do at work. For auditing sake, here is the comparison between master and my fix: master...lel-amri:issue-334 |
Hello!
I am working inside an OpenShift ENV and trying to use img.
I can explain my problem in short: When I try to build an image - I get the follwing error message:
Do you have an Idea what I could do to get img run inside my OpenShift-Env?
Thank you very much!
The text was updated successfully, but these errors were encountered: