CentOS as a Docker host causes different container behavior compared to any other host OS
<p>I am working with Docker on different Hosts : RHEL7 , SELS12 and CentOS7,
And i found a different behavior in containers which running on CentOS7 as Docker Host, comparing to containers which running on SLES12 or RHEL7 as Docker hosts.   </p>

<p>The different behavior is related to those common issues in Docker containers: 
<a href="https://github.com/docker/docker/issues/7147" rel="nofollow noreferrer">https://github.com/docker/docker/issues/7147</a><br><a href="https://github.com/docker/docker/issues/6800" rel="nofollow noreferrer">https://github.com/docker/docker/issues/6800</a></p>

<h2>In container with CentOS7 as Docker host:</h2>

<p>I <strong>have a permission</strong> to resolve a symbolic in the path: /proc/1<br>
command: <code>ls -la /proc/1</code>
<a href="https://i.stack.imgur.com/6RBAg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/6RBAg.png" alt="enter image description here"></a></p>

<p>Start command of the container:<br></p>

<pre><code>docker run -it --name=nessi_centos_test centos:latest bash
</code></pre>

<h2>But in containers with SLES12 or RHEL7 as Docker hosts:</h2>

<p>I <strong>get permission denied</strong> with the same command, as you can see in the above links.<br>
command: <code>ls -la /proc/1</code>
<a href="https://i.stack.imgur.com/iS7Aj.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/iS7Aj.png" alt="enter image description here"></a></p>

<h2>Additional information:</h2>

<p>Relied on <a href="https://docs.docker.com/engine/security/security/" rel="nofollow noreferrer">Docker security documentation</a>  the containers by default start with restricted set of Linux kernel capabilities.</p>

<p>One of those capabilities is: CAP_SYS_PTARCE<br> 
this capability exists by default in any Linux host machine:<br>
<br>
Example in Linux machine:<br>
<a href="https://i.stack.imgur.com/ou1uj.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ou1uj.png" alt="enter image description here"></a></p>

<p>But in all containers it is missing by default (unless you start the container with --cap-add=sys_ptrace)<br>
<br>
Example in Container:
<a href="https://i.stack.imgur.com/JtYN1.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/JtYN1.png" alt="enter image description here"></a>
you can see here that the container have a restricted set of capabilities that not include the sys_ptrace capability.
<br></p>

<p>So if i start the containers with --cap-add=sys_ptrace in RHEL or SLES as Docker hosts, I get the same behavior as I get in the CentOS 7 as a Docker host.
<br>
<br>
Example:
Docker host: RHEL7<br>
Docker image: centos:latest (same as before )<br>
<code>Strat command: docker run -it --name=nessi_centos_test5 --cap-add=sys_ptrace centos:latest bash</code><br></p>

<p><a href="https://i.stack.imgur.com/6RPrZ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/6RPrZ.png" alt="enter image description here"></a>
<a href="https://i.stack.imgur.com/74gOz.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/74gOz.png" alt="enter image description here"></a></p>

<p>as you can see here, for getting the same behavior as I get in CentOS 7 I need to start my containers with additional sys_ptrace capability.<br></p>

<h2>Technical Information:</h2>

<ol>
<li>The different CentOS 7 behavior:    Run command in container:<br><code>ls -la /proc/1</code><br> results:  no errors </li>
<li>The regular behavior of other hosts (RHEL7 and SLES12)  Run command
in container:<br> <code>ls -la /proc/1</code><br> results:</li>
</ol>

<p><code>ls: cannot read symbolic link /proc/1/cwd: Permission denied
 ls: cannot read symbolic link /proc/1/root: Permission denied
 ls: cannot read symbolic link /proc/1/exe: Permission denied</code></p>

<ol>
<li><strong>The different CentOS 7 behavior reproduced in:<br></strong></li>
</ol>

<p>[root@localhost Desktop]# <strong>uname -a</strong><br>
Linux localhost.localdomain 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<br>
<br></p>

<p>[root@localhost Desktop]# <strong>docker info</strong><br>
Containers: 1<br>
 Running: 0<br>
 Paused: 0<br>
 Stopped: 1<br>
Images: 1<br>
Server Version: 1.11.2<br>
Storage Driver: devicemapper<br>
 Pool Name: docker-253:0-136686025-pool<br>
 Pool Blocksize: 65.54 kB<br>
 Base Device Size: 10.74 GB<br>
 Backing Filesystem: xfs<br>
 Data file: /dev/loop0<br>
 Metadata file: /dev/loop1<br>
 Data Space Used: 324.3 MB<br>
 Data Space Total: 107.4 GB<br>
 Data Space Available: 35.43 GB<br>
 Metadata Space Used: 847.9 kB<br>
 Metadata Space Total: 2.147 GB<br>
 Metadata Space Available: 2.147 GB<br>
 Udev Sync Supported: true<br>
 Deferred Removal Enabled: false<br>
 Deferred Deletion Enabled: false<br>
 Deferred Deleted Device Count: 0<br>
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data<br>
 WARNING: Usage of loopback devices is strongly discouraged for production use. <br>Either use <code>--storage-opt dm.thinpooldev</code> or use <code>--storage-opt &lt;br&gt;dm.no_warn_on_loop_devices=true</code> to suppress this warning.<br>
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata<br>
 Library Version: 1.02.107-RHEL7 (2016-06-09)<br>
Logging Driver: json-file<br>
Cgroup Driver: cgroupfs<br>
Plugins: <br>
 Volume: local<br>
 Network: null host bridge<br>
Kernel Version: 3.10.0-327.22.2.el7.x86_64<br>
Operating System: CentOS Linux 7 (Core)<br>
OSType: linux<br>
Architecture: x86_64<br>
CPUs: 1<br>
Total Memory: 993.3 MiB<br>
Name: localhost.localdomain<br>
ID: BPVJ:YDPR:4VUO:WNBN:DVZH:7MEH:TPMP:Y3MP:GMN7:UT36:LQ74:GJ4N<br>
Docker Root Dir: /var/lib/docker<br>
Debug mode (client): false<br>
Debug mode (server): false<br>
Registry: <a href="https://index.docker.io/v1/" rel="nofollow noreferrer">https://index.docker.io/v1/</a><br>
WARNING: bridge-nf-call-iptables is disabled<br>
WARNING: bridge-nf-call-ip6tables is disabled<br>
<br>
<br></p>

<p><strong>Docker images:</strong><br>
centos:latest<br>
ubuntu:14.04<br>
<br>
<strong>Also tested on:</strong><br>
Docker daemon version : 1.10.2<br>
<br>
<br></p>

<ol start="2">
<li><strong>The regular behavior of other hosts (RHEL7 and SLES12)</strong><br>
<br>
<strong>RHEL7 as Docker host:</strong><br>
<br>
[root@localhost ~]# <strong>uname -a</strong><br>
Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
[root@localhost ~]# <strong>docker info</strong><br>
Containers: 14<br>
Running: 6<br>
Paused: 0<br>
Stopped: 8<br>
Images: 22<br>
Server Version: 1.11.2<br>
Storage Driver: devicemapper<br>
Pool Name: docker-253:0-67168288-pool<br>
Pool Blocksize: 65.54 kB<br>
Base Device Size: 10.74 GB<br>
Backing Filesystem: xfs<br>
Data file: /dev/loop0<br>
Metadata file: /dev/loop1<br>
Data Space Used: 9.66 GB<br>
Data Space Total: 107.4 GB<br>
Data Space Available: 16.27 GB<br>
Metadata Space Used: 7.68 MB<br>
Metadata Space Total: 2.147 GB<br>
Metadata Space Available: 2.14 GB<br>
Udev Sync Supported: true<br>
Deferred Removal Enabled: false<br>
Deferred Deletion Enabled: false<br>
Deferred Deleted Device Count: 0<br>
Data loop file: /var/lib/docker/devicemapper/devicemapper/data<br>
WARNING: Usage of loopback devices is strongly discouraged for production use. <br>Either use <code>--storage-opt dm.thinpooldev</code> or use <code>--storage-opt dm.no_warn_on_loop_devices=true</code> to suppress this warning.<br>
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata<br>
Library Version: 1.02.107-RHEL7 (2015-12-01)<br>
Logging Driver: json-file<br>
Cgroup Driver: cgroupfs<br>
Plugins:<br>
Volume: local<br>
Network: null host bridge<br>
Kernel Version: 3.10.0-123.el7.x86_64<br>
Operating System: Red Hat Enterprise Linux<br>
OSType: linux<br>
Architecture: x86_64<br>
CPUs: 2<br>
Total Memory: 1.798 GiB<br>
Name: localhost.localdomain<br>
ID: VL2V:RUOZ:U55X:OCEQ:MAS6:MXYV:CKUY:WJQY:3KH3:LWPW:LUYH:E3MM<br>
Docker Root Dir: /var/lib/docker<br>
Debug mode (client): false<br>
Debug mode (server): false<br>
Registry: <a href="https://index.docker.io/v1/" rel="nofollow noreferrer">https://index.docker.io/v1/</a><br>
WARNING: bridge-nf-call-iptables is disabled<br>
WARNING: bridge-nf-call-ip6tables is disabled<br>
<br>
<br>
<strong>Docker images:</strong><br>
centos:latest<br>
centos:7<br>
ubuntu:14.04<br>
ubuntu:latest<br>
rhel:latest<br>
suse/sles12:latest (the image build on SLES machine and copied to RHEL)<br>
<br>
<strong>Also tested on:</strong><br>
Docker daemon version : 1.10.3. 1.9<br>
<br>
<br>
<strong>SLES12 as Docker host:</strong><br>
<br></li>
</ol>

<p>linux-ojix:~ # <strong>uname -a</strong><br>
Linux linux-ojix 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux
<br>
<br></p>

<p>linux-ojix:~ # <strong>docker info</strong><br>
Containers: 6<br>
 Running: 3<br>
 Paused: 0<br>
 Stopped: 3<br>
Images: 10<br>
Server Version: 1.10.3<br>
<br></p>

<p>Storage Driver: btrfs<br>
 Build Version: Btrfs v3.18.2+20150430<br>
 Library Version: 101<br>
Execution Driver: native-0.2<br>
Logging Driver: json-file<br>
Plugins:<br>
 Volume: local<br>
 Network: bridge null host<br>
Kernel Version: 3.12.28-4-default<br>
Operating System: SUSE Linux Enterprise Server 12<br>
OSType: linux<br>
Architecture: x86_64<br>
CPUs: 2<br>
Total Memory: 1.853 GiB<br>
Name: linux-ojix<br>
ID: NU4F:MOFR:RTUA:F2OM:4G67:NMGV:76S6:BONN:ASD5:XGHF:KVJQ:N242<br>
WARNING: No swap limit support<br>
<br>
<br>
<strong>Docker images:</strong><br>
centos:latest<br>
centos:7<br>
ubuntu:14.04<br>
ubuntu:latest<br>
suse/sles12:latest <br>
<br>
<br>
<br>
<strong>Does anyone understand why CentOS as a Docker host causes different container behavior (ls –la /proc/1 in the container - no error) compared to any other host OS (ls –la /proc/1 in the container - with permission denied errors)?</strong></p>