Bug 1603201

Summary: [Regression] docker can't bindmount symbolic links to namespaces (/proc/PID/ns/*)
Product: Red Hat Enterprise Linux 7 Reporter: Sergio Lopez <slopezpa>
Component: dockerAssignee: Frantisek Kluknavsky <fkluknav>
Status: CLOSED ERRATA QA Contact: atomic-bugs <atomic-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 7.5CC: aivaraslaimikis, amurdaca, dornelas, dzhukous, fkluknav, gscrivan, lfriedma, lsm5, lsu, pdwyer, sauchter
Target Milestone: rcKeywords: Extras, Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, bind mounts were resolved before using them inside a container. Consequently, symlinks could not be mounted inside of the container. With this update, the source of a bind mount is not resolved. As a result, it is possible to bind mount symlinks again into a container.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-16 16:05:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1186913, 1571903    

Description Sergio Lopez 2018-07-19 12:41:53 UTC
Description of problem:

Starting on version docker-1.13.1-63.git94f4240.el7.x86_64, docker can't no longer bindmount symbolic links to namespaces (/proc/PID/ns/*):

# docker run --privileged -it  -v /proc/1/ns/net:/aaa rhel7 /bin/bash
/usr/bin/docker-current: Error response from daemon: error while creating mount source path '/proc/1/ns/net:[4026531956]': mkdir /proc/1/ns/net:[4026531956]: no such file or directory.

This worked on previous versions (docker-1.13.1-58.git87f2fab.el7.x86_64 or lower).


Version-Release number of selected component (if applicable):

docker-1.13.1-63.git94f4240.el7.x86_64


How reproducible:

Always.


Additional info:

This problem can be tracked down to this change:

 - https://github.com/projectatomic/docker/commit/1fc7510329f938b7d38fd8989bd462201d0fe13a

volume/volume.go:
 // Setup sets up a mount point by either mounting the volume if it is
 // configured, or creating the source directory if supplied.
-func (m *MountPoint) Setup(mountLabel string, rootUID, rootGID int) (path string, err error) {
+func (m *MountPoint) Setup(prefix, mountLabel string, rootUID, rootGID int) (path string, err error) {
+	symlinkRoot := prefix
+	if symlinkRoot == "" {
+		symlinkRoot = "/"
+	}
+	sourcePath, err := symlink.FollowSymlinkInScope(filepath.Join(prefix, m.Source), symlinkRoot)
+	if err != nil {
+		path = ""
+		err = errors.Wrapf(err, "error evaluating symlink from mount source '%s'", m.Source)
+		return
+	}
+

The use of FollowSymlinkInScope on m.Source alters docker's by following symlinks in the source path of the bindmount. In the case of a symbolic link to a namespace, it produces the following transformation:

 - /proc/1/ns/net -> /proc/1/ns/net:[4026531956]

And the later doesn't really exist in the filesystem.

I've checked upstream, and this change isn't there, so this is a downstream regression.

Comment 4 Giuseppe Scrivano 2018-07-19 14:29:44 UTC
Pull requests here:

https://github.com/projectatomic/docker/pull/316
https://github.com/projectatomic/docker/pull/317

Sergio, we are using this feature in the docker system container, so this is probably not useful upstream.

Comment 5 Sergio Lopez 2018-07-19 14:41:10 UTC
Hi Giuseppe,

Thanks for the explanation and the quick fix. I'll create a test build once the PRs are merged.

Sergio (slp).

Comment 19 Luwen Su 2018-08-05 17:36:31 UTC
Package version:
docker-1.13.1-74.git6e3bb8e.el7.x86_64

# docker run --privileged -it  -v /proc/1/ns/net:/aaa rhel7 /bin/bash
[root@ab28cbc039d9 /]# ls /aaa
/aaa
[root@ab28cbc039d9 /]# exit
exit

Comment 22 errata-xmlrpc 2018-08-16 16:05:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2482