Description
As mentioned in docker/cli#1358 (comment) I have, for some reason, an /etc/docker directory owned by root:root with permissions 0700.
At first I thought this might be intentional since there can be sensitive files in there, however upon reflection I think this is unintentional, sensitive files (such as /etc/docker/key.json) themselves have permissions 0600 already.
Steps to reproduce the issue:
I don't know, I just found it like that and it's probably been that way for ages unnoticed. It's quite possibly an old bug, or maybe even be an old packaging bug, which has left these permissions in place.
Code inspection leads me to at least one place, in the Swarm init, which I believe would create the directory with these permissions if it didn't already exist: See https://github.com/moby/moby/blob/master/daemon/cluster/cluster.go#L139. It's entirely plausible that I did a docker swarm init at some point before /etc/docker existed.
Doing git grep os.Mkdir.*0700 gives a page or so of matches, which I've not been through to determine which are applied to /etc/docker vs elsewhere.
Describe the results you received:
$ stat -c %a /etc/docker
700
Describe the results you expected:
Probably:
$ stat -c %a /etc/docker
755
Additional information you deem important (e.g. issue happens only occasionally):
I did notice that Debian's docker.io package (which I do not use, I use the download.docker.com version) ensures this directory is created by the package install with perms 0755 (and has a postinst to correct previously buggy versions which left it as 0700), that came about from Debian #831324.
The packages from download.docker.com do not, AFAICT, create this directory nor fiddle with the permissions (perhaps they should).
Output of docker version:
It's unlikely that this directory was created by the current version of docker, but anyway:
Client:
Version: 18.06.0-ce
API version: 1.38
Go version: go1.10.3
Git commit: 0ffa825
Built: Wed Jul 18 19:09:33 2018
OS/Arch: linux/amd64
Experimental: true
Server:
Engine:
Version: 18.06.0-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: 0ffa825
Built: Wed Jul 18 19:07:38 2018
OS/Arch: linux/amd64
Experimental: false
Output of docker info:
Containers: 9
Running: 4
Paused: 0
Stopped: 5
Images: 164
Server Version: 18.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: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.14.0-3-amd64
Operating System: Debian GNU/Linux buster/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.53GiB
Name: bokrug
ID: AU33:BO7D:7VGM:MOLB:RSDF:IBRV:GCWT:THHM:OEVM:TX3C:BNLM:WHAR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 47
Goroutines: 60
System Time: 2018-09-13T10:33:42.646335921+01:00
EventsListeners: 0
Username: ijc25
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
172.16.10.239:5000
172.16.14.104:5000
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Additional environment details (AWS, VirtualBox, physical, etc.):
Description
As mentioned in docker/cli#1358 (comment) I have, for some reason, an
/etc/dockerdirectory owned byroot:rootwith permissions0700.At first I thought this might be intentional since there can be sensitive files in there, however upon reflection I think this is unintentional, sensitive files (such as
/etc/docker/key.json) themselves have permissions0600already.Steps to reproduce the issue:
I don't know, I just found it like that and it's probably been that way for ages unnoticed. It's quite possibly an old bug, or maybe even be an old packaging bug, which has left these permissions in place.
Code inspection leads me to at least one place, in the Swarm init, which I believe would create the directory with these permissions if it didn't already exist: See https://github.com/moby/moby/blob/master/daemon/cluster/cluster.go#L139. It's entirely plausible that I did a
docker swarm initat some point before/etc/dockerexisted.Doing
git grep os.Mkdir.*0700gives a page or so of matches, which I've not been through to determine which are applied to/etc/dockervs elsewhere.Describe the results you received:
Describe the results you expected:
Probably:
Additional information you deem important (e.g. issue happens only occasionally):
I did notice that Debian's
docker.iopackage (which I do not use, I use thedownload.docker.comversion) ensures this directory is created by the package install with perms0755(and has a postinst to correct previously buggy versions which left it as0700), that came about from Debian #831324.The packages from
download.docker.comdo not, AFAICT, create this directory nor fiddle with the permissions (perhaps they should).Output of
docker version:It's unlikely that this directory was created by the current version of docker, but anyway:
Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):