Bad volume path sanitisation and checks. #10409
Description
It seems as though we aren't doing rigorous enough checks RE: volume mountpoints.
NOTE: This is not a security bug due to a happy coincidence (that
evalSymlinksInScopechecks that the path given is inside the root and that the vulnerable code usesevalSymlinksInScope).
You can very easily create broken Docker images by setting VOLUME . (which resolves to VOLUME / but doesn't cause a build-time error):
% cat Dockerfile
FROM ubuntu
VOLUME .
% docker build .
Sending build context to Docker daemon 3.584 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu
---> b39b81afc8ca
Step 1 : VOLUME .
---> Running in dd918b329f03
---> 14ac081ecf99
Removing intermediate container dd918b329f03
Successfully built 14ac081ecf99
% docker run -it 14ac081ecf99 /bin/bash
finalize namespace close open file descriptors open /proc/self/fd: no such file or directoryFATA[0016] Error response from daemon: Cannot start container e5652e02cc11d12812a4e9c5bd1a01389610f00c
0b9f7bbb66520798dcc0e22b: finalize namespace close open file descriptors open /proc/self/fd: no such file or directory
Luckily, this bug doesn't allow you to bindmount outside the container rootfs (although it's due to a side-effect of evalSymlinksInScope and is not by design). However, it is indicative of serious problems in Docker regarding path sanitisation.
% cat Dockerfile
FROM ubuntu
VOLUME ..
% docker build .
Sending build context to Docker daemon 3.584 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu
---> b39b81afc8ca
Step 1 : VOLUME ..
INFO[0002] evalSymlinksInScope: /var/lib/docker/devicemapper/mnt/61994871840cc69de113a642d8f3447890580c5dd43dc117d7442383b96325ff is not in /var/lib/docker/devicemapper/mnt/61994871840cc69de113a
642d8f3447890580c5dd43dc117d7442383b96325ff/rootfs