os/user: LookupId panics on Linux+glibc static build #24787
Comments
dsnet
changed the title
|
This isn't really |
It is only fixed in Go 1.11 which is not here yet, and the archive/tar started to use os/user in 1.10. So, 1.11 should be fine, and 1.9 was fine, but Go 1.10 is broken in this very case. |
As this looks to be the only alternative, please let me know if you want me to do a packport. |
FiloSottile
added
the
CherryPickCandidate
|
@kolyshkin The CL to be backported would be https://golang.org/cl/92456, correct? @ianlancetaylor any objection to cherry-picking? |
|
We can't backport that CL by itself, because it wasn't tested and didn't work (#24841, #24845). It would need at least also CLs 106837, 107299, 107304. And in my opinion the sequence of problems and failed fixes means that the risk is too high for a backport to a release branch. Not to mention the fact that this requires the user to understand the problem--it's really not obvious that a crash while using archive/tar should be fixed by using In my opinion the latter problem means that there is still a problem to fix here. The |
|
I actually don't understand where this crash is coming from, and I don't understand how to recreate it. @kolyshkin Do you have step by step instructions I can use to create the problem? |
andybons
removed
the
CherryPickCandidate
@ianlancetaylor unfortunately not. Before filing this bug I spent some time trying to create a simple reproducer but failed. Perhaps it requires some specific version of glibc, or there is something else absent from the simple reproducers I tried. What we see in docker CI is here moby/moby#35739 (comment) Let me try again to create a repro |
|
It looks like the reason of segfault is indeed a glibc bug described here: #13470 |
|
and here's a reproducer, modeled after the one in C from #13470 (comment) package main
import (
"fmt"
"os/user"
)
func main() {
id := "3"
wait := make(chan bool)
ret := make(chan *user.User)
go func() {
<-wait
u, _ := user.LookupId(id)
ret <- u
}()
u, _ := user.LookupId(id)
wait <- true
fmt.Printf("%+v\n", u)
u = <-ret
fmt.Printf("%+v\n", u)
}When compiled statically (i.e. |
Producing a static build already requires a non-trivial amount of flags passed to
...and this magic string keeps growing. Perhaps the solution is to encapsulate this knowledge internally, exposing it via a new One other good thing such a flag could also do is to add |
|
@kolyshkin I suggest that you open a new bug for a I'm inclined to close this bug. I don't see what we can change in Go to fix it. There is a workaround, as you know. |
Done, see #26492 |
|
Closing based on #24787 (comment) |
1. LookupId panics on Linux+glibc static build (golang/go#24787) 2. Updated go version to 1.11.0 in Dockerfile.build 3. added go build tags netgo osusergo in static binary
1. LookupId panics on Linux+glibc static build (golang/go#24787) 2. Updated go version to 1.11.0 in Dockerfile.build 3. added go build tags netgo osusergo in static binary Signed-off-by: vijaysamanuri <vijay.samanuri@wavemaker.com>
Since Go 1.10 beta, using
tar.FileInfoHeader()is not possible from a static binary compiled on Linux/glibc. This is caused by commit 0564e30 ("archive/tar: populate uname/gname/devmajor/devminor in FileInfoHeader") which makes use ofos/userfunctionsLookupIdandLookupGroupId, which, in turn, use glibc'sgetpw*andgetgrp*calls (in case CGO is available).This breaks both Docker (moby/moby#35739 (comment)) and containerd.
This issue is a manifestation of a problem described in more details at #23265 and remedied by commit 62f0127 ("os/user: add a way to enforce pure Go implementation"). Unfortunately, the remedy will only be available in Go 1.11, and requires setting a
osusergobuild tag for static build.PS this report is serving merely to document the issue and maybe help others who see the same issue. I do not expect this to be fixed in Go 1.10. As a workaround, a fork of
archive/taris created with the partial revert of 0564e30 here: https://github.com/kolyshkin/go-tar/tree/go-1.10What version of Go are you using (
go version)?1.10.1
Does this issue reproduce with the latest release?
yes (1.10.1)
What operating system and processor architecture are you using (
go env)?Linux/amd64
What did you do?
Switched to Go 1.10 to compile Docker (moby/moby#35739).
What did you expect to see?
no panic
What did you see instead?
panic while running CI
The text was updated successfully, but these errors were encountered: