Cli: Non-root user "docker login" results in panic SIGSEGV segmentation violation

[brenc]

Description

Fresh install on Debian Buster. Using a non-root user who is a member of the docker group I started getting a panic when running docker login for the first time after install. This seems to be a new issue.

Steps to reproduce the issue:

1. Create a new user who is a member of the docker group
2. Run docker login

Describe the results you received:

$ docker login
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x55b37f2d0406]

goroutine 1 [running]:
github.com/docker/cli/cli/command.ConfigureAuth(0x55b380d12fe0, 0xc000505520, 0x0, 0x0, 0x0, 0x0, 0x0, 0x55b380c82401, 0xc0000812d0, 0xc000727968)
        /go/src/github.com/docker/cli/cli/command/registry.go:128 +0x46
github.com/docker/cli/cli/command/registry.runLogin(0x55b380d12fe0, 0xc000505520, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:123 +0x223
github.com/docker/cli/cli/command/registry.NewLoginCommand.func1(0xc0006a22c0, 0x55b381d1d5c8, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:45 +0xcc
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).execute(0xc0006a22c0, 0xc0006915c0, 0x0, 0x0, 0xc0006a22c0, 0xc0006915c0)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:850 +0x462
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc00050fb80, 0xc0006915c0, 0x1, 0x1)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:958 +0x34b
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:895
main.runDocker(0xc000505520, 0x55b380c85120, 0xc000010028)
        /go/src/github.com/docker/cli/cmd/docker/docker.go:287 +0x1d3
main.main()
        /go/src/github.com/docker/cli/cmd/docker/docker.go:298 +0xf3

This also happens when I try to log into our private registry.

Describe the results you expected:

Being prompted for username/password info to log into the registry.

Additional information you deem important (e.g. issue happens only occasionally):

If I use Ansible to log into the registry, it works. Once .docker/config.json is created (either by hand or via Ansible) I can type docker login and I'll get the usual username prompt. If I move the .docker dir and type docker login I get the panic again.

Output of docker version:

$ docker version
Client: Docker Engine - Community
 Version:           20.10.1
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        831ebea
 Built:             Tue Dec 15 04:34:48 2020
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       f001486
  Built:            Tue Dec 15 04:32:45 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.0-docker)

Server:
 Containers: 2
  Running: 1
  Paused: 0
  Stopped: 1
 Images: 2
 Server Version: 20.10.1
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk s
yslog
 Swarm: active
  NodeID: xv0jr9ztk2ilprmm7lpah16uk
  Is Manager: true
  ClusterID: n94lxrdxn8e5v2a8bjmupupum
  Managers: 3
  Nodes: 3
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 10.10.1.60
  Manager Addresses:
   10.10.1.60:2377
   10.10.1.61:2377
   10.10.1.62:2377
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.19.0-13-amd64
 Operating System: Debian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 987.2MiB
 Name: staging-docker01
 ID: 56GF:S23G:QA4Q:IPVK:ULMZ:LHUR:AWS5:AQSN:LW42:4DP5:QJ7B:XEAU
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

This is a Proxmox VM but this also happens on hardware. I've tested it with other non-root users and get the same result.

[69teen]

I run the same problem. All I have to do is remove golang-docker-credential-helpers packet.
dpkg -r --ignore-depends=golang-docker-credential-helpers golang-docker-credential-helpers

More info about the issue you can read here: https://github.com/docker/compose/issues/6023

[brenc]

@69teen hrmm yeah, looks like this package gets installed along with python-docker which Ansible requires. I will have to look into using a venv again.

[MatthiasKuklinski]

Can confirm, since I ran into the same issue.

After removing golang-docker-credential-helpers, as advised by @69teen, I was able to execute az login successfully. docker-compose requires python-dockerpycreds, which in turn depends on golang-docker-credential-helpers. Therefore executing docker login, while docker-compose is installed (more precisely golang-docker-credential-helpers), as of now, won't work.

[suityou01]

It's not such an uncommon use case to have both docker and docker-compose installed. Is there a plan to fix this or come up with a workaround at least?

[thaJeztah]

Previous reports with the credential helpers from that package were related to https://github.com/docker/docker-credential-helpers/issues/103, which was fixed in https://github.com/docker/docker-credential-helpers/pull/29 (credential helpers v0.6.2), but I think that the Debian and Ubuntu packages that bundle the credential-helpers have not yet been updated by the package maintainers.

Not sure why it now manifests as a panic in the CLI itself though

[moracabanas]

It's not such an uncommon use case to have both docker and docker-compose installed. Is there a plan to fix this or come up with a workaround at least?

Weird behaviour in my case:

I use Ubuntu 20.04 on WSL2 with docker.
I open a Ubuntu terminal then docker login, so the output is normal:

Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username:

then I open the current dir with VSCode code . so in the VSCode console which sould be the same console as opening a Ubuntu terminal docker login actually outputs this:

<3>init: (6990) ERROR: UtilConnectToInteropServer:300: connect failed 2
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x562e4c979d76]

goroutine 1 [running]:
github.com/docker/cli/cli/command.ConfigureAuth(0x562e4e5bace0, 0xc00035ed00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x562e4e52a101, 0xc0001a4940, 0xc000585968)
        /go/src/github.com/docker/cli/cli/command/registry.go:128 +0x46
github.com/docker/cli/cli/command/registry.runLogin(0x562e4e5bace0, 0xc00035ed00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:123 +0x223
github.com/docker/cli/cli/command/registry.NewLoginCommand.func1(0xc0005b0580, 0x562e4f5c5448, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:45 +0xcc
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).execute(0xc0005b0580, 0xc000317b10, 0x0, 0x0, 0xc0005b0580, 0xc000317b10)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:850 +0x462
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc00042bb80, 0xc000317b10, 0x1, 0x1)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:958 +0x34b
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:895
main.runDocker(0xc00035ed00, 0x562e4e52cde0, 0xc00010a010)
        /go/src/github.com/docker/cli/cmd/docker/docker.go:287 +0x1d3
main.main()
        /go/src/github.com/docker/cli/cmd/docker/docker.go:298 +0xf3

My workflow is based on local docker-compose testing stacks -> local docker swarm staging stacks -> production docker swarm, so getting this error and having to decide between pushing images to docker registry and testing stacks with docker-compose just breaks my entire workflow.
Is my use case a bad practice at all?

Thanks you for taking your time to review this issue.

EDIT: I do not understand what happened with this issue but I got it solved with this

[moracabanas]

The error was related to this thread in my case https://github.com/microsoft/WSL/issues/5065

[thaJeztah]

I think this may have been introduced in https://github.com/docker/cli/pull/2818. Let me open a pull-request to fix

[thaJeztah]

opened https://github.com/docker/cli/pull/2918 with a fix

[ebleb]

The issue still persists for me, I'm using docker version 20.10.2.

[thaJeztah]

https://github.com/docker/cli/pull/2918 was merged after 20.10.2, and has not yet made it into a release, so that's expected