os/user: LookupGroup does not identify all cases of UnknownGroupError #40334
Comments
|
Further debugging of the issue revealed the issue to actually be related to the fact that we are in the chroot, and hence we do not have things like systemd userdb to respond, however the chroot still had this in it's /etc/nsswitch.conf: notice So it seems to be that really we have an issue with NSS in this chroot that gets bubbled up to |
toothrot
changed the title
toothrot
added
the
NeedsInvestigation
|
/cc @bradfitz @kevinburke |
|
Interesting... I'll try to take a look later this week. I don't think this is important enough to get through the code freeze so we'd be targeting 1.15.1 or 1.16 (another way of saying that the fix will not show up in a public release for a while). |
|
Checking through nss_systemd code, I do not see it returning anything unusual on the nss module level. It returns things like |
|
I'm having trouble reproducing. I am running the same program you are: package main
import (
"fmt"
"os/user"
)
func main() {
_, err := user.LookupGroup("thisdoesnotexist")
fmt.Printf("%#v\n", err)
switch err.(type) {
case user.UnknownGroupError:
fmt.Println("successful error handling")
default:
fmt.Printf("error, not matchable (type %T), %v\n", err, err)
}
}in then sharing the compiled binary into a Docker container: running copying these files into the chroot: # mkdir /go/test/lib/x86_64-linux-gnu
# cp -r --dereference /lib/x86_64-linux-gnu/* /go/test/lib/x86_64-linux-gnu(and similar for the other files) then, finally, running the program: Running with strace (you have to install it into that container): So it looks like my program is trying to read /etc/group and failing (a failure I would expect in the chroot). My understanding is /etc/group parse is fallback logic if cgo is not enabled, though I am compiling on Linux with a linux target, so cgo should be enabled... I don't know strace well enough to determine whether getgrnam_r is the one that is trying and failing to read /etc/group, ie. cgo is enabled but it's still failing to read the file, though I am concerned that I am getting different output than you got. |
|
Odd... I copied the contents of os/user to a third party package so I could add print statements to it, and when I do that, it compiles and runs successfully. |
|
I can share a reproducer environment when I get a chance, sorry been busy with other things... should be soon though |
|
Fwiw, I can easily reproduce this by installing the (tested the issue with sssd on 20.04 and 21.10 and the fix as well). Alternatively the |
When the `sssd` package is installed on a Ubuntu system the
`TestUserMaybeSudoUser` test will fail because then `user.Lookup`
returns a generic error
```
user: lookup username guy: no such file or directory
```
because in the go layer the getpw{uid,nam}_r() returned ENOENT.
This is already reported upstream as
golang/go#40334
This commit works around this upstream issue by checking for
ENOENT on the error from user.Lookup(). It's not nice but the
best I could come up to to handle this case. On my 21.10 system
sssd is installed as part of `ubuntu-desktop-minimal`.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
As described here golang/go#40334 incorrect system configuration can lead user.LookupGroup to return ENOENT. We've already added a workaround #18981, but this one place seems to be forgotten. I also added ESRCH to ignored errors as newer glibc returns it. The error was exposed after updating our docker image to Ubuntu 20.04 #26905 which includes newer Glibc.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
I only tested Go 1.14.5, I did not test Go 1.14.6 or tip.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
https://play.golang.org/p/qEi8JbjG5-4 when built on Linux and run inside a Ubuntu 20.10 chroot inside a Ubuntu 16.04 LXD container inside an Ubuntu 16.04 VM (this setup comes from a cloud building environment) fails to identify the returned error as
a user.UnknownGroupError.I suspect there is something about the implementation that is specific to the chroot, as running the same program outside of the chroot (inside the LXD container) successfully returns. See:
It's possible something about
getgrpnam_rin the version of glibc in Ubuntu 20.10 has changed to return a different error code, but as per the man page ofgetgrpnam_runder "Notes", there are numerous possible error codes that could be used to identifyuser.UnknownGroupError:As such, I would expect Go to do a "best effort" job at identifying errors returned as
user.UnknownGroupError, including at least the documentedENOENT,ESRCH,EBADF,EPERMcases mentioned in the man page (in this case it isESRCHthat is being returned).Finally, note that the same problem hypothetically affects
user.Lookupand the associateduser.UnknownUserError, but getpwnam_r is not acting up the same waygetgrpnam_ris here.What did you expect to see?
I expected the program when run inside the chroot to work the same as outside of the chroot.
What did you see instead?
Inside the chroot it fails to identify the returned error as
user.UnknownGroupError.The text was updated successfully, but these errors were encountered: