Bug 1465485 - Mount points from first container namespace leak into systemd-machined namespace
Mount points from first container namespace leak into systemd-machined namespace
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: systemd-maint
qe-baseos-daemons
:
Depends On:
Blocks: 1463534
  Show dependency treegraph
 
Reported: 2017-06-27 10:06 EDT by Sergio Lopez
Modified: 2017-07-12 09:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-12 09:26:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergio Lopez 2017-06-27 10:06:04 EDT
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.
Comment 4 Lukáš Nykrýn 2017-07-11 10:51:43 EDT
Hmm I've tried this on 7.3 and 7.4 and I was not able to reproduce the mentioned behavior.
Comment 5 Sergio Lopez 2017-07-12 08:52:14 EDT
Hi Lukáš,

I've just tried on a clean 7.3 machine and wasn't able to reproduce the issue neither.

I'm going to assume something was wrong with my previous setup (perhaps multiple containerd instances running at the same time?) and, if you're ok with it, I'll close this bug with NOTABUG.

Sorry for the noise.
Sergio.
Comment 6 Lukáš Nykrýn 2017-07-12 09:26:00 EDT
Thanks for verification :-) This issue looked pretty weird, to be honest I could not think up a scenario where it would happen.

But anyway, if you see it again feel free to reopen the bug.

Note You need to log in before you can comment on or make changes to this bug.