Description of problem:

Some mount points from the first container created are leaked into systemd-machined namespace.


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

Tested with systemd-219-30.el7_3.9.x86_64


How reproducible:

Always


Steps to Reproduce:
1. Make sure systemd-machined is not running.

# ps -ef | grep systemd-machined

2. Start a container

# docker run -it rhel7-atomic /bin/bash

3. List namespaces

# lsns
        NS TYPE  NPROCS   PID USER COMMAND
4026531836 pid      160     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026531837 user     161     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026531838 uts      160     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026531839 ipc      160     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026531840 mnt      155     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026531856 mnt        1    27 root kdevtmpfs
4026531956 net      159     1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026532154 mnt        1   545 root /usr/lib/systemd/systemd-udevd
4026532190 mnt        2   793 root /usr/sbin/NetworkManager --no-daemon
4026532196 mnt        1   445 root /bin/bash
4026532197 uts        1   445 root /bin/bash
4026532198 ipc        1   445 root /bin/bash
4026532199 pid        1   445 root /bin/bash
4026532201 net        1   445 root /bin/bash
4026532299 net        1   464 root /usr/lib/systemd/systemd-machined
4026532390 mnt        1   464 root /usr/lib/systemd/systemd-machined

4. Peek into systemd-machined namespace to see if there's a container related mount points

# nsenter -t 464 --mount mount |grep docker
proc on /run/docker/netns/9900e278e359 type proc (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/rhel-root on /var/lib/docker/containers type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
shm on /var/lib/docker/containers/21a0071f74b14a27bcdfb455b61cee15a2217b225e261b64c521c8f90acbd753/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c550,c892",size=65536k)
/dev/mapper/rhel-root on /var/lib/docker/devicemapper type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/docker-253:0-17624426-d51415cc54e615d3c1599750d7dde5e1b0b3beba6765dd531dc7494b0aa51919 on /var/lib/docker/devicemapper/mnt/d51415cc54e615d3c1599750d7dde5e1b0b3beba6765dd531dc7494b0aa51919 type xfs (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c550,c892",nouuid,attr2,inode64,sunit=1024,swidth=1024,noquota)


Actual results:

Some container related mount points are present in systemd-machined namespace. This will cause trouble when the container tries to clean up its layers.


Expected results:

No foreign mount points should be present in systemd-machined namespace.


Additional info:

I took a look into F25 systemd, and this doesn't happen because the following directives are not present in the service definition:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=full
ProtectHome=yes

Modifying the service definition in RHEL73 to match the directives in F25 fixes the problem but 1) I'm not sure if there are any side effects, and 2) It's very probably that there's a bug in the implementation of those directives, as I don't think any of them should cause the leak of the mount points on purpose.