10. mnt名前空間 - 余談: マウントプロパゲーション
マウントイベントの伝播を制御する仕組み
あるマウントポイント以下へのmount/unmountのイベントを、
関係するマウントポイントに伝播するかどうか。
shared(双方向) slave(一方向) private(伝播しない)
10
$ mkdir src dest src/{master,slave}
# mount --bind src dest # srcをdestにbindする
# mount --make-slave dest # masterからslaveへは伝播する
# mount -t tmpfs tmpfs src/master # マウント元(src)へのマウント
# mount -t tmpfs tmpfs dest/slave # マウント先(dest)へのマウント
$ mount
tmpfs on /home/alice/src/master type tmpfs (rw,relatime,seclabel)
tmpfs on /home/alice/dest/master type tmpfs (rw,relatime,seclabel)
tmpfs on /home/alice/dest/slave type tmpfs (rw,relatime,seclabel)
15. net名前空間
unshare --net で新しいnet名前空間でプロセスを起動
ただし ip(1) を使った方が名前付きで作れるのでおすすめ
/var/run/netns 以下に指定された名前でprocfsがマウントされる
15
$ sudo ip netns add test # testという名前でnetnsを作成
$ sudo ip netns list # 名前空間一覧
test
$ sudo ip netns exec test /bin/bash # test名前空間でプロセスを起動
# readlink /proc/$$/ns/net # netns確認
net:[4026532219]
# ls -li /var/run/netns/test # /var/run/netns以下にファイルができる
4026532219 -r--r--r--. 1 root root 0 Oct 18 03:02 /run/netns/test
# ip addr # loインターフェースしか見えない
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
16. net名前空間 - 余談: veth
通信するために仮想ethインタフェース(veth)を作って遊んでみる
1. vethペア(master/slave)の作成とnetnsの設定
16
$ sudo ip link add name master type veth peer name slave # vethペア作成
$ sudo ip addr # 確認
6: slave: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 3a:64:e8:80:03:5f brd ff:ff:ff:ff:ff:ff
7: master: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 86:cf:cc:26:74:e4 brd ff:ff:ff:ff:ff:ff
$ sudo ip link set slave netns test # 片方をnetns testに移動
$ sudo ip addr # インターフェースの確認
7: master: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 86:cf:cc:26:74:e4 brd ff:ff:ff:ff:ff:ff
$ sudo ip netns exec test ip addr
6: slave: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 3a:64:e8:80:03:5f brd ff:ff:ff:ff:ff:ff
17. net名前空間 - 余談: veth
通信するために仮想ethインタフェース(veth)を作って遊んでみる
2. IPアドレス割り振り & 疎通確認
17
$ sudo ip addr add 192.168.50.101/24 dev master # masterにIPアドレス設定
$ sudo ip link set dev master up # リンクアップ
$ sudo ip netns exec test /bin/bash # 名前空間内にbash起動
# ip addr add 192.168.50.102/24 dev slave # slaveにIPアドレス設定
# ip link set dev slave up # リンクアップ
# ping 192.168.50.101 -c1 # 疎通確認
PING 192.168.50.101 (192.168.50.101) 56(84) bytes of data.
64 bytes from 192.168.50.101: icmp_seq=1 ttl=64 time=0.047 ms
# exit
$ ping 192.168.50.102 -c1
18. net名前空間 - 余談: veth
通信するために仮想ethインタフェース(veth)を作って遊んでみる
3. IPマスカレードの設定 & 外部ネットーワークへの疎通確認
18
$ sudo ip netns exec test /bin/bash
# ip route add default via 192.168.50.101 dev slave # default gw の設定
# ip route
default via 192.168.50.101 dev slave
192.168.50.0/24 dev slave proto kernel scope link src 192.168.50.102
# exit
$ # IPマスカレードの設定
$ sudo iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o eth0 -j MASQUERADE
$ sudo ip netns exec test /bin/bash
# ping 8.8.8.8 -c1 # 外部への疎通確認
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.18 ms
FreeBSD: Jail
Solaris : Solaris Containers (2005)
Docker(2013)
http://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/
That said, Red Hat disabled them, because we think that user namespaces need to incubate in the upstream community longer to fully understand the security implications and mitigate/remediate any exploits/attack vectors that could expose our customers to malicious activity.
Put differently, as with all of Red Hat’s enterprise products, including our solutions that focus on Linux containers (like Red Hat Enterprise Linux Atomic Host and OpenShift Enterprise 3), we don’t enable features until we are sure that they are ready for enterprise use.
http://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/
That said, Red Hat disabled them, because we think that user namespaces need to incubate in the upstream community longer to fully understand the security implications and mitigate/remediate any exploits/attack vectors that could expose our customers to malicious activity.
Put differently, as with all of Red Hat’s enterprise products, including our solutions that focus on Linux containers (like Red Hat Enterprise Linux Atomic Host and OpenShift Enterprise 3), we don’t enable features until we are sure that they are ready for enterprise use.
1982年3月18日のFree BSD実装が初出
TECH PREVIEW: Overlay filesystem may not be fully supported
Red Hat Enterprise Linux 7.1 では OverlayFS はテクノロジープレビューとしての対応になります。現在、以下の 2 つの制限があります。
下部のファイルシステムには ext4 の使用を推奨しています。
xfs および gfs2 ファイルシステムには対応していません。
- SELinux には対応していないため、OverlayFS を使用する場合は enforcing モードを無効にしてください。