Description
Happening in: Docker 17.06.0-ce
Not happening in: 17.05.0-ce
In Docker 17.05.0-ce, executing docker cp hostfile container:containerpath will copy files from the host to the container setting the uid/gid to main user inside the container.
Since Docker 17.06.0-ce (and as a result of #28923), the behavior of docker cp has changed, breaking things.
Now, docker cp hostfile container:containerpath will copy a file from the host to the container but preserving the original uid/gid (with the respective mapping to the container). docker cp -a hostfile container:containerpath (as defined in the documentation) is meant to "copy all uid/gid information" but it is in fact setting the uid and gid to the main user inside the container.
Old behavior has been broken and switched.
This breaks, for example, things like docker cp authorized_keys containerid:/root/.ssh/authorized_keys because it wont set the uid/gid to the main user inside the container (old behavior) but will try to preserve the original uid/gid of the file, making it now owned by the container main user and preventing SSH daemon from working with it.
Steps to reproduce the issue:
0. touch myfile && chmod 777 myfile
- docker cp myfile <container_id>:/tmp
- ls -la myfile
- docker exec <container_id> ls -la /tmp/myfile
Describe the results you received:
[] user@host /tmp $ ls -la myfile
-rwxrwxrwx 1 user user 0 Jul 13 17:31 myfile
[] user@host /tmp $ docker exec e1bc960a6b25 ls -la /tmp/myfile
-rwxrwxrwx 1 user user 0 Jul 13 17:31 /tmp/myfile
Describe the results you expected:
[] user@host /tmp $ ls -la myfile
-rwxrwxrwx 1 user user 0 Jul 13 17:31 myfile
[] user@host /tmp $ docker exec e1bc960a6b25 ls -la /tmp/myfile
-rwxrwxrwx 1 root root 0 Jul 13 17:31 /tmp/myfile
Additional information you deem important (e.g. issue happens only occasionally):
The user user already exists in the container
Output of docker version:
Docker version 17.06.0-ce, build 02c1d87
Output of docker info:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 1
Server Version: 17.06.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 16.04.2 LTS (containerized)
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 58.97GiB
Name: dockerdev
ID: EF5Q:FGB7:EPWN:44QQ:5L5K:BE4S:KUJF:UADH:GLMF:KUW7:H363:WWUA
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: chipironcin
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
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.):
Tested in two different AWS EC2 machines
Description
Happening in: Docker 17.06.0-ce
Not happening in: 17.05.0-ce
In Docker 17.05.0-ce, executing
docker cp hostfile container:containerpathwill copy files from the host to the container setting the uid/gid to main user inside the container.Since Docker 17.06.0-ce (and as a result of #28923), the behavior of
docker cphas changed, breaking things.Now,
docker cp hostfile container:containerpathwill copy a file from the host to the container but preserving the original uid/gid (with the respective mapping to the container).docker cp -a hostfile container:containerpath(as defined in the documentation) is meant to "copy all uid/gid information" but it is in fact setting the uid and gid to the main user inside the container.Old behavior has been broken and switched.
This breaks, for example, things like
docker cp authorized_keys containerid:/root/.ssh/authorized_keysbecause it wont set the uid/gid to the main user inside the container (old behavior) but will try to preserve the original uid/gid of the file, making it now owned by the container main user and preventing SSH daemon from working with it.Steps to reproduce the issue:
0. touch myfile && chmod 777 myfile
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
The user
useralready exists in the containerOutput of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Tested in two different AWS EC2 machines