sysfs appears to be bind mounted into containers which use non-host networking

[maybe-sybr]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
When running containers with networking stacks which I expect to be isolated from the host, I can still see the host's sysfs rather than the namespace's.

Steps to reproduce the issue:

1. podman run --rm -ti --network slirp4netns docker.io/alpine sh -c 'ip l; ls -l /sys/class/net'

Describe the results you received:

[maybe@zen podman]$ podman run --rm -ti --network slirp4netns docker.io/alpine sh -c 'ip l; ls -l /sys/class/net'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether ca:79:79:8b:39:4e brd ff:ff:ff:ff:ff:ff
total 0
lrwxrwxrwx    1 nobody   nobody           0 Dec 13 22:42 dummy0 -> ../../devices/virtual/net/dummy0
lrwxrwxrwx    1 nobody   nobody           0 Dec 13 22:42 enp0s20f0u3u4 -> ../../devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.4/2-3.4:1.0/net/enp0s20f0u3u4
lrwxrwxrwx    1 nobody   nobody           0 Dec 13 22:42 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx    1 nobody   nobody           0 Dec 13 22:42 wlo1 -> ../../devices/pci0000:00/0000:00:14.3/net/wlo1

Describe the results you expected:
/sys/class/net should not have host networking nodes listed, and should instead have the slirp created tap0 in there along with an lo. Running a mount -t sysfs sysfs /sys in the container ensures the container's sysfs is mounted but needs --privileged to do the overmount.

[maybe@zen podman]$ podman run --rm -ti --network slirp4netns --privileged docker.io/alpine sh -c 'mount -t sysfs sysfs /sys; ip l; ls -l /sys/class/net'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether 1e:79:a0:7e:f1:bd brd ff:ff:ff:ff:ff:ff
total 0
lrwxrwxrwx    1 root     root             0 Dec 14 01:33 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx    1 root     root             0 Dec 14 01:33 tap0 -> ../../devices/virtual/net/tap0

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 2.2.1

Output of podman info --debug:

Package info (e.g. output of rpm -q podman or apt list podman):

podman-2.2.1-1.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

[mheon]

Likely cause: #8561 went too far in pruning down the cases where we mount our own sysfs.

…

On Sun, Dec 13, 2020 at 8:35 PM maybe-sybr ***@***.***> wrote: *Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)* /kind bug *Description* When running containers with networking stacks which I expect to be isolated from the host, I can still see the host's sysfs rather than the namespace's. *Steps to reproduce the issue:* 1. podman run --rm -ti --network slirp4netns docker.io/alpine sh -c 'ip l; ls -l /sys/class/net' *Describe the results you received:* ***@***.*** podman]$ podman run --rm -ti --network slirp4netns docker.io/alpine sh -c 'ip l; ls -l /sys/class/net' 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN qlen 1000 link/ether ca:79:79:8b:39:4e brd ff:ff:ff:ff:ff:ff total 0 lrwxrwxrwx 1 nobody nobody 0 Dec 13 22:42 dummy0 -> ../../devices/virtual/net/dummy0 lrwxrwxrwx 1 nobody nobody 0 Dec 13 22:42 enp0s20f0u3u4 -> ../../devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.4/2-3.4:1.0/net/enp0s20f0u3u4 lrwxrwxrwx 1 nobody nobody 0 Dec 13 22:42 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 nobody nobody 0 Dec 13 22:42 wlo1 -> ../../devices/pci0000:00/0000:00:14.3/net/wlo1 *Describe the results you expected:* /sys/class/net should not have host networking nodes listed, and should instead have the slirp created tap0 in there along with an lo. Running a mount -t sysfs sysfs /sys in the container ensures the container's sysfs is mounted but needs --privileged to do the overmount. ***@***.*** podman]$ podman run --rm -ti --network slirp4netns --privileged docker.io/alpine sh -c 'mount -t sysfs sysfs /sys; ip l; ls -l /sys/class/net' 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN qlen 1000 link/ether 1e:79:a0:7e:f1:bd brd ff:ff:ff:ff:ff:ff total 0 lrwxrwxrwx 1 root root 0 Dec 14 01:33 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root 0 Dec 14 01:33 tap0 -> ../../devices/virtual/net/tap0 *Additional information you deem important (e.g. issue happens only occasionally):* *Output of podman version:* podman version 2.2.1 *Output of podman info --debug:* *Package info (e.g. output of rpm -q podman or apt list podman):* podman-2.2.1-1.fc33.x86_64 *Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?* Yes *Additional environment details (AWS, VirtualBox, physical, etc.):* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8707>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCBAQZBUJWPJA2NPGBDSUVTULANCNFSM4UZ66YAA> .

[maybe-sybr]

Sounds about right, @mheon . I was just looking through what had changed since the last RPM release since I recall updating at the end of last week. Downgrading to podman-2.1.1-10.fc33 and containers-common-1.2.0-3.fc33 fixed the misbehaviour. Thanks for the quick reply. I'll work with the downgraded versions for now and keep an eye on this issue for any updates.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I believe this is fixed in the main branch now, reopen if I am mistaken.

[mheon]

This is not fixed. Discussion is ongoing in #8949

[giuseppe]

this should be fixed by: #8949