rootless: access denied to files in non-primary group

[virtuald]

Description

Steps to reproduce the issue:

1. Install rootless docker
2. Add your user to another group other than your primary (in this case, I'm using the 'kvm' group)
3. Make a directory for testing, and as root:

# echo "contents" > somefile
# chown root:kvm somefile
# chmod 0660 somefile

4. Verify permissions on host as user

$ ls -l something
-rw-rw---- 1 root kvm 9 Nov 18 12:48 something
$ cat something 
contents

5. Logout/login, start rootless docker
6. docker run --rm -it --privileged -v $(pwd):/demo ubuntu:18.04
7. Try to access file from inside container

root@57858f00f5c5:/# ls -l /demo/something 
-rw-rw---- 1 nobody nogroup 9 Nov 18 17:48 /demo/something
root@57858f00f5c5:/# cat /demo/something 
cat: /demo/something: Permission denied

Describe the results you received:

See above.

Describe the results you expected:

I expect host behavior and container behavior to be the same.

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

• I first ran into this when trying to access the /dev/kvm device on my machine, which by default is only setup as root/kvm 0660.
• I've tried running with and without --privileged
• I've tried changing my UID/GID in the container
• This is specific to rootless docker.

Output of docker version:

$ docker version
Client: Docker Engine - Community
 Version:           master-dockerproject-2019-11-14
 API version:       1.41
 Go version:        go1.12.12
 Git commit:        6c12a82f
 Built:             Thu Nov 14 23:54:05 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          master-dockerproject-2019-11-14
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.4
  Git commit:       44d3901
  Built:            Fri Nov 15 00:01:01 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.3.0
  GitCommit:        36cf5b690dcc00ff0f34ff7799209050c3d0c59a
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: master-dockerproject-2019-11-14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
 Logging Driver: json-file
 Cgroup Driver: none
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 36cf5b690dcc00ff0f34ff7799209050c3d0c59a
 runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
  rootless
 Kernel Version: 4.15.0-39-generic
 Operating System: Ubuntu 16.04.5 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 40
 Total Memory: 125.6GiB
 Name: hostname
 ID: GDZU:YAVS:7B62:HWPQ:IIKT:M3PR:B7PV:TSHH:IFGT:P3MW:BSRQ:S5K4
 Docker Root Dir: /home/dustin.spicuzza/.local/share/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: No swap limit support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

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

I've tried this on Ubuntu 16.04 and 18.04 with the same results.

[virtuald]

I've found a workaround. First, find the id of the supplementary group:

$ grep kvm /etc/group
kvm:x:10124:dustin.spicuzza

Then modify /etc/subgid to map in the KVM group for my user:

$ grep dustin /etc/subgid
dustin.spicuzza:10124:1
dustin.spicuzza:755360:65535

Once I restart docker and start a container, it works fine. You can see the gid_map has been adjusted to map the group into the container... albeit, at id 1 (the 'daemon' user), but the mapping could be massaged to something more sensible:

$ docker run --rm -it --privileged -v $(pwd):/demo ubuntu:18.04
root@1729b01b60a7:/# cat demo/something
cat: demo/something: Permission denied
root@1729b01b60a7:/# newgrp daemon
root@1729b01b60a7:/# cat demo/something
contents

I'm uncertain of the security ramifications of this? Quoting https://www.redhat.com/sysadmin/rootless-podman (I know podman and docker are different but I suspect this applies here):

... you need to follow these rules for security... No UID or GID goes into the container if it’s in use on the host.

[AkihiroSuda]

I think your workaround is fine