docker run -w -u sets wrong uid/gid for working directory

[rittneje]

Description

When setting the working directory via docker run -w, if the directory doesn't exist in the image, it will be automatically created. However, it is always owned by root:root, regardless of the -u flag, which means the directory is unusable.

Steps to reproduce the issue:

1. docker run --rm -it -u 1000:1000 -w /tmp/foo ubuntu:bionic
2. ls -lsa

Describe the results you received:

4 drwxr-xr-x 2 root root 4096 Mar  9 20:43 .
4 drwxrwxrwt 1 root root 4096 Mar  9 20:43 ..

Describe the results you expected:

The directory should be owned by uid 1000.

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

Output of docker version:

Client:
 Cloud integration: v1.0.22
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:46:56 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.5.0 (74594)
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 46
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 1.938GiB
 Name: docker-desktop
 ID: IUZR:PCCH:2BCW:R6KM:DSS4:OMY5:ZOPX:3O6X:XBHI:X5ZZ:MTUX:S3IW
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

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

[ndeloof]

Daemon code indeed creates working directory as root: https://github.com/moby/moby/blob/16009830c2e2f3840ee73459918289f4bf54bd1d/container/container.go#L277 I agree doing so makes it impossible to access working directory as a non-root user, and it would make sense created working directory is owned by container's user, but changing this behavior might have some impacts. Any thoughts @thaJeztah?

[thaJeztah]

Yes, this may be related to the same underlying cause of https://github.com/moby/moby/issues/20295 (for the classic builder) (and some of the related/duplicates https://github.com/moby/moby/issues/36408, https://github.com/moby/moby/issues/36677).

The actual error happening in this case may be something that only started to become an issue after a bugfix / security fix in runc (where permissions were not applied soon enough, therefore the user process getting access to paths it shouldn't have access to).

I recall a lot of debating happening about WORKDIR (and COPY, ADD) not following the USER directive, and changing it was rejected by the BDFOL (I wasn't a maintainer yet at the time 😅, but tried to unblock that in https://github.com/moby/moby/pull/9934).

That said; I know the behavior for WORKDIR at least changed in BuildKit (which now does respect USER), so perhaps we should change the -w / --workdir accordingly. Of course we should check if there's possible consequences / breaking changes, but generally, I'm tempted to say that if the user specifies a workdir (and docker creating that), it'd be implicitly expected that that user can also use the directory.

[c-ameron]

@thaJeztah does that mean that having a --chown for WORKDIR is now possible? That would be so helpful!

[ndeloof]

@thaJeztah can you please unasign this issue, I'm obviously not actively working on it :)

[thaJeztah]

done!