cgroup なのか cgroups なのか
割とどーでもいい話(でも気になってた人多いはずw)
以前、第4回のコンテナ勉強会でも質問が出たのですが、cgroup/cgroups という機能の正式な名称は cgroup なのか cgroups なのか、というのはよくわかりませんでした。
私は、英語って単数・複数をきちんと使い分けるし、cgroup は複数のサブシステム・コントローラが存在するので、海外の人は "cgroups" と複数形で使うんだろうなあと思ってました。機能自体を指しているのか、コントローラ群を含めて指しているのかって、曖昧な文脈も多いですし。
しかし、この論争にもついにピリオドが打たれました。カーネル付属文書の cgroup-v2.txt をご覧ください。
"cgroup" stands for "control group" and is never capitalized. The
https://www.kernel.org/doc/Documentation/cgroup-v2.txt
singular form is used to designate the whole feature and also as a
qualifier as in "cgroup controllers". When explicitly referring to
multiple individual control groups, the plural form "cgroups" is used.
"cgroup" は "control group" を表します。大文字では表記することはありま
せん。単数形は全機能を表したり、"cgroup controllers" のように修飾子と
して全機能を表すために使います。明確に複数の個別の control groups を示
すときに、複数形の "cgroups" を使います。
Tejun Heo 氏は非英語ネイティブと想像しているのできっとその辺りが気になっていたんだ、なのでそこをはっきりさせたんだ、と妄想しています(笑)。
まあ相変わらず cgroup v1 については明確な定義が書かれてるわけではないんですがね (^_^;)
4.5 カーネルで stable となった cgroup の単一階層構造 cgroup v2 の io コントローラ
Control Group v2
以前も少し紹介していましたし、連載でも少し触れましたが、今広く (?) 使われている cgroup は色々問題があって、単一階層構造の cgroup が開発されていました。この辺りは
- Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForwardの日記
- Linux 3.16 から試せる cgroup の単一階層構造 (2) - TenForwardの日記
で紹介しました。
以前は開発中の機能だったため、マウントするときに "__DEVEL__sane_behavior" などというふざけたオプションが必要でした。(^^)
この後も順調に (?) 開発はすすみ、4.5 カーネルのリリースでついにこの機能が stable となったようで、"__DEVEL__" というプレフィックスも不要になりましたし、正式な機能で「まともなふるまい」なんてのはないだろうという話があったのかなかったのか知りませんが、名前も "Control Group v2" という名前になったようです。今までのは "v1" です。
ドキュメントは
にあります。
前に試した時は v1 にあったコントローラ (サブシステム) が全部現れていましたが、正式リリースとなった 4.5 の時点で有効なコントローラは memory, io, pid の 3 つだけのようです。
v1 の問題点のひとつに、コントローラがばらばらに実装されているため、コントローラ間の連携ができないという問題がありました。このため、blkio というブロックデバイスに対する I/O 制限を行うコントローラがあるにもかかわらず、通常のファイル I/O (の書き込み) に対する制限ができませんでした (memory と連携できていないため)。
この辺りは「第4回 コンテナ型仮想化の情報交換会@東京」で @hiro_kamezawa さんにお話頂いたので、詳細をお知りになりたい方はそちらをどうぞ。
v2 では、階層構造が単一となって、この辺りの制限ができるようになりました。昨年の LinuxCon で Heo Tejun 氏が ext2 に対応したという話をされていましたが、4.5 を見てみると ext2, ext4, btrfs に対して制限がかかるようです。
というわけで、この制限が働くのか簡単に試してみました。
kernel は 4.6-rc3、ファイルシステムは ext2 と ext4 で試しています。
かなり適当な確認なので、間違いとかあるかもしれませんので、気づいたら優しく教えてください。
v1 のおさらい
v2 を試す前に、まずは v1 の blkio コントローラのおさらいをしておきましょう。direct I/O 以外では制限がかかっていないことも確認してみました。
v1 準備
"test01" cgroup を作成して、/dev/vdb に対する 1MB/sec の読み書きの制限を設定してみました。
- cgroup 作成
# mkdir /sys/fs/cgroup/blkio/test01
- プロセスを "test01" へ登録
# echo $$ > /sys/fs/cgroup/blkio/test01/tasks
- /dev/vdbに対する制限を設定
# ls -l /dev/vdb
brw-rw---- 1 root disk 254, 16 Apr 13 06:30 /dev/vdb (デバイス番号の確認)
# echo "254:16 1048576" > /sys/fs/cgroup/blkio/test01/blkio.throttle.read_bps_device (読み込み制限)
# echo "254:16 1048576" > /sys/fs/cgroup/blkio/test01/blkio.throttle.write_bps_device (書き込み制限)
v1 を使った書き込み制限 (direct I/O)
# dd oflag=direct if=/dev/zero of=/data/testfile bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.00347 s, 1.0 MB/s
実行時に iostat を実行しました。出力の一部。
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vdb 258.59 0.00 1034.34 0 1024 vdb1 258.59 0.00 1034.34 0 1024
書き込みが 1MB/sec に制限されていますね。
v1 を使った読み込み制限 (direct I/O)
# dd iflag=direct if=/data/testfile of=/dev/null bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0018 s, 1.0 MB/s
同様に iostat 出力の一部。
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vdb 261.22 1044.90 0.00 1024 0 vdb1 261.22 1044.90 0.00 1024 0
読み込みが 1MB/sec に制限されています。
v1 を使った書き込み制限
"oflag=direct" を指定せずに dd を実行してみると、
# dd if=/dev/zero of=/data/testfile bs=4K count=1048576 ^C636264+0 レコード入力 636264+0 レコード出力 2606137344 バイト (2.6 GB) コピーされました、 22.6348 秒、 115 MB/秒
# iostat -p vdb 1 | grep "vdb " :(略) vdb 311.00 12.00 315392.00 12 315392 vdb 339.00 12.00 344064.00 12 344064 vdb 456.57 12.12 434424.24 12 430080 vdb 389.53 4.65 351255.81 4 302080 vdb 11.00 0.00 9216.00 0 9216 vdb 39.00 8.00 33688.00 8 33688 vdb 35.00 0.00 31940.00 0 31940 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 :(略) vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 84.21 4.21 73675.79 4 69992 vdb 140.43 0.00 126012.77 0 118452 vdb 11.11 4.04 9002.02 4 8912 vdb 507.22 12.37 443455.67 12 430152 vdb 410.10 12.12 376501.01 12 372736 vdb 1.00 0.00 912.00 0 912
制限はかかっていませんね。書き込まれたらしばらく 0 の時間があり、また書き込みが再開されているのがわかります。
v1 を使った読み込み制限
"iflag=direct" を外して実行します。実行前にキャッシュクリアします。
# echo 3 > /proc/sys/vm/drop_caches (キャッシュクリア) # dd if=/data/testfile of=/dev/null bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0036 s, 1.0 MB/s
読み込みは制限がききますね。
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vdb 8.25 1055.67 0.00 1024 0 vdb1 8.25 1055.67 0.00 1024 0
cgroup v2 の io コントローラ
v2 の準備
v2 は "cgroup2" という名前でマウントします。名前以外は以前試した「まともなふるまい」時代とあまり変わりません。
- /sys/fs/cgroup にマウント。
mount -t cgroup2 cgroup /sys/fs/cgroup/
- ルート cgroup の確認。ファイルが 3 つだけです
# ls /sys/fs/cgroup/
cgroup.controllers cgroup.procs cgroup.subtree_control - 使えるコントローラを確認
# cat /sys/fs/cgroup/cgroup.controllers
io memory pids - "memory" と "io" をサブ cgroup で使えるようにします
# cat /sys/fs/cgroup/cgroup.subtree_control (サブ cgroup で使えるコントローラ一覧の確認。デフォルトは空)
# echo "+memory +io" > /sys/fs/cgroup/cgroup.subtree_control (io と memory を追加)
# cat /sys/fs/cgroup/cgroup.subtree_control (再度確認)
io memory (登録されている) - "test01" cgroup 作成
mkdir /sys/fs/cgroup/test01 (作成)
"test01"でioとmemoryが使えるのが確認できました
# ls /sys/fs/cgroup/test01 (test01ディレクトリの確認)
cgroup.controllers io.max memory.events memory.stat
cgroup.events io.stat memory.high memory.swap.current
cgroup.procs io.weight memory.low memory.swap.max
cgroup.subtree_control memory.current memory.max
# cat /sys/fs/cgroup/test01/cgroup.controllers (test01で使えるコントローラの確認)
io memory
v2 で direct I/O 制限
まずは v1 でもちゃんと制限された direct I/O を確認しました。
まずは書き込み。
# dd oflag=direct if=/dev/zero of=/data/testfile bs=4K count=1024 1024+0 レコード入力 1024+0 レコード出力 4194304 バイト (4.2 MB) コピーされました、 4.0041 秒、 1.0 MB/秒
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vdb 261.22 0.00 1044.90 0 1024 vdb1 261.22 0.00 1044.90 0 1024
読み込み。
# dd iflag=direct if=/data/testfile of=/dev/null bs=4K count=1024 1024+0 レコード入力 1024+0 レコード出力 4194304 バイト (4.2 MB) コピーされました、 4.00393 秒、 1.0 MB/秒
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vdb 261.22 1044.90 0.00 1024 0 vdb1 261.22 1044.90 0.00 1024 0
v1 と同じく制限されています。
v2 で読み込み制限
少し大きなファイルで確認しました。
# echo 3 > /proc/sys/vm/drop_caches # dd if=/data/testfile of=/dev/null bs=4K count=1048576 ^C4605+0 レコード入力 4604+0 レコード出力 18857984 バイト (19 MB) コピーされました、 18.1077 秒、 1.0 MB/秒
iostat の出力は
# iostat -p vdb 1 | grep "vdb " vdb 30.83 2378.02 10808.93 1864321 8473984 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 7.07 630.30 0.00 624 0 vdb 8.08 1034.34 0.00 1024 0 vdb 8.00 1024.00 0.00 1024 0 vdb 8.08 1034.34 0.00 1024 0 vdb 8.00 1024.00 0.00 1024 0 vdb 8.08 1034.34 0.00 1024 0 :(略)
これは v1 と同じように制限がかかります。
v2 で書き込み制限
さて、いよいよハイライト。
# dd if=/dev/zero of=/data/testfile bs=4K count=1048576 ^C51563+0 レコード入力 51563+0 レコード出力 211202048 バイト (211 MB) コピーされました、 35.7076 秒、 5.9 MB/秒
# iostat -p vdb 1 | grep "vdb " vdb 28.16 2182.44 9794.36 1888229 8473984 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 0.00 0.00 0.00 0 0 vdb 36.17 144.68 0.00 136 0 vdb 1.05 0.00 842.11 0 800 vdb 1.01 0.00 517.17 0 512 vdb 1.00 0.00 508.00 0 508 vdb 1.01 0.00 783.84 0 776 vdb 3.00 0.00 1160.00 0 1160 vdb 1.00 0.00 1004.00 0 1004 vdb 1.01 0.00 1034.34 0 1024 vdb 1.01 0.00 1034.34 0 1024 vdb 1.01 0.00 1034.34 0 1024 vdb 1.01 0.00 1034.34 0 1024 vdb 0.99 0.00 1013.86 0 1024 vdb 2.02 0.00 1046.46 0 1036 vdb 2.00 0.00 1024.00 0 1024 vdb 1.01 0.00 1034.34 0 1024
落ち着くまで少し時間があるのと、一瞬 1024 以上の値が出てますが、大体きれいに 1024 (KB) で制限されています。
まとめ
とりあえずディスクへの書き込みがちゃんと制限されているっぽいです (たぶん)。
cgroup namespace (2)
前回は /proc/$PID/cgroup ファイルが Namespace を反映した形で記載されているのを見ました。
とりあえずここまで。これだけだとすでにマウントされている cgroupfs はそのままの元のディレクトリ階層で見えるので、/proc/$PID/cgroup だけ見え方が変わっても意味がないような気がしますが、改めて cgroupfs のマウントを試すとエラーになりますし、どうするものなのかちょっとまだ見えてないので、またわかれば続編を書く予定です。
と書きましたが、試したところちゃんと cgroupfs も Namespace ごとに見えるようになったので紹介しておきます。前回何をボケて失敗していたのかわかりませんが、以下のように普通に簡単な処理をやっただけです。
- まずは "test01" cgroup を作成します (memory だけ)
# mkdir -p /sys/fs/cgroup/memory/test01/
- 現在のシェルを "test01" の tasks に登録します
# echo $$ > /sys/fs/cgroup/memory/test01/tasks
- namespace内の cgroupfs をホストから見て別のところにマウントするために、LXC コンテナ用のツリーを借ります
# cd /var/lib/lxc/test01/rootfs/
- unshare で chroot を実行します
# unshare -C chroot $PWD
- namespace 内で proc をマウントし、/sys/fs/cgroup を tmpfs でマウントします。これは特に不要な気がしますが
# mount -n -t proc proc /proc
# mount -n -t tmpfs none /sys/fs/cgroup/ - memory サブシステムを /sys/fs/cgroup/memory にマウントします
# mkdir /sys/fs/cgroup/memory
# mount -n -t cgroup -o memory memory /sys/fs/cgroup/memory/
マウントできたので、確認してみます。
# ls /sys/fs/cgroup/memory/ cgroup.clone_children memory.memsw.failcnt cgroup.event_control memory.memsw.limit_in_bytes cgroup.procs memory.memsw.max_usage_in_bytes memory.failcnt memory.memsw.usage_in_bytes memory.force_empty memory.move_charge_at_immigrate memory.kmem.failcnt memory.numa_stat memory.kmem.limit_in_bytes memory.oom_control memory.kmem.max_usage_in_bytes memory.pressure_level memory.kmem.slabinfo memory.soft_limit_in_bytes memory.kmem.tcp.failcnt memory.stat memory.kmem.tcp.limit_in_bytes memory.swappiness memory.kmem.tcp.max_usage_in_bytes memory.usage_in_bytes memory.kmem.tcp.usage_in_bytes memory.use_hierarchy memory.kmem.usage_in_bytes notify_on_release memory.limit_in_bytes tasks memory.max_usage_in_bytes
普通にマウントできていて、"test01" cgroup は存在しませんね。つまりここが cgroupfs のルートなわけです。
では、ここに "test02" cgroup を作ってみましょう。
root@enterprise:~# mkdir /sys/fs/cgroup/memory/test02 root@enterprise:~# ls -d /sys/fs/cgroup/memory/test02 /sys/fs/cgroup/memory/test02/ root@enterprise:~# ls /sys/fs/cgroup/memory/test02 cgroup.clone_children memory.memsw.failcnt cgroup.event_control memory.memsw.limit_in_bytes cgroup.procs memory.memsw.max_usage_in_bytes :(略)
/sys/fs/cgroup/memory 直下に test02 というディレクトリができて、中も普通にファイルができています。
"test02" にプロセスを登録して /proc/$PID/cgroup を確認してみましょう。
# echo $$ > /sys/fs/cgroup/memory/test02/tasks # echo $$ 8574 # cat /proc/self/cgroup 14:debug:/ 13:pids:/ 12:hugetlb:/ 11:net_prio:/ 10:perf_event:/ 9:net_cls:/ 8:freezer:/ 7:devices:/ 6:memory:/test02 5:blkio:/ 4:cpuacct:/ 3:cpu:/ 2:cpuset:/ 1:name=systemd:/
ちゃんと Namespace 内の cgroup ツリーになってますね。
ここで、元のホスト上の Namespace から "test01" と "test02" を確認してみましょう。
$ ls -d /sys/fs/cgroup/memory/test01 /sys/fs/cgroup/memory/test01/ $ ls -d /sys/fs/cgroup/memory/test01/test02 /sys/fs/cgroup/memory/test01/test02/
作成した cgroup namespace の外では "test01" の下に "test02" がありますね。tasks ファイルも確認してみると、
$ cat /sys/fs/cgroup/memory/test01/test02/tasks 8574
シェルの PID が登録されていますね。
cgroup namespace (1)
以前、RHEL6 のころに ns cgroup ってサブシステムが cgroup にありましたが、それとは別のお話。
4.6 カーネルに入る cgroup namespace のお話です (Ubuntu 16.04 のカーネルには入るようです) 。namespace ごとに別の cgroup ツリーが見えるようにするものかな。
軽く試してみました。
準備
(2016-04-12 追記) 今だと 4.6-rc? で試せます
とりあえず cgroup namespace の機能が入ったカーネルは
の "2016-03-21/nsroot" というブランチのものを使いました。出来上がったカーネルはこんな
$ uname -r 4.5.0-rc1-plamo64-cgns-00009-g37bbd8c-dirty
(-plamo64 は make menuconfig で指定してる文字列)
cgroup namespace が作れる unshare を含む util-linux は
から。こちらも "2016-03-02/cgns" というブランチを元にパッチを作って util-linux-2.27.1 に当てました。
実行
とりあえず /proc/$PID/cgroup ファイルで見える cgroup のパスが Namespace ごとに独立して見えるみたい。この様子を見てみました。
まずは現在のシェルを cgroup に所属させます。memory サブシステムのみ "test01" に所属させてみました。
# echo $$ > /sys/fs/cgroup/memory/test01/tasks
この状態で同じシェル上で /proc/self/cgroup を確認してみましょう。
# cat /proc/self/cgroup
13:debug:/
12:pids:/
11:hugetlb:/
10:net_prio:/
9:perf_event:/
8:net_cls:/
7:freezer:/
6:devices:/
5:memory:/test01
4:blkio:/
3:cpuacct:/
2:cpu:/
1:cpuset:/
memory は /test01 になっていますね。
ここでパッチを当てた unshare コマンドで新しい cgroup namespace を作成します。-C が cgroup namespace を作るオプションです。
# unshare -C
# cat /proc/self/cgroup
13:debug:/
12:pids:/
11:hugetlb:/
10:net_prio:/
9:perf_event:/
8:net_cls:/
7:freezer:/
6:devices:/
5:memory:/
4:blkio:/
3:cpuacct:/
2:cpu:/
1:cpuset:/
# echo $$
22302
memory の部分が "/test01" でなく、"/" になっていますね。最後に現在のシェルの PID を確認しています。
この PID の cgroup 情報を別のシェル (元の cgroup namespace にいるシェル) から見てみます。
# cat /proc/22302/cgroup 13:debug:/ 12:pids:/ 11:hugetlb:/ 10:net_prio:/ 9:perf_event:/ 8:net_cls:/ 7:freezer:/ 6:devices:/ 5:memory:/test01 4:blkio:/ 3:cpuacct:/ 2:cpu:/ 1:cpuset:/
作成した namespace の外から見るとちゃんと "/test01" になっていますね。
/proc/$PID/ns/cgroup ファイルも確認しておきましょう。
# ls -l /proc/1/ns/cgroup lrwxrwxrwx 1 root root 0 4月 6日 06:59 /proc/1/ns/cgroup -> cgroup:[4026531835] # ls -l /proc/22273/ns/cgroup lrwxrwxrwx 1 root root 0 4月 6日 07:17 /proc/22302/ns/cgroup -> cgroup:[4026532404]
リンク先が異なりますので違う namespace にいることがわかります。これはこれまでの他の namespace と同じですね。
プロセスが cgroup 間を移動したとき
プロセスを cgroup 間で移動させると面白い見え方をします。まず "test01" と同じ階層に "test02" を作成し、先ほどのプロセスを "test01" から "test02" に移動させます。
# mkdir /sys/fs/cgroup/memory/test02 # echo 22302 > /sys/fs/cgroup/memory/test02/tasks
先ほど unshare して作った namespace 内のシェルから /proc/$PID/cgroup ファイルを見てみると、
# cat /proc/self/cgroup 13:debug:/ 12:pids:/ 11:hugetlb:/ 10:net_prio:/ 9:perf_event:/ 8:net_cls:/ 7:freezer:/ 6:devices:/ 5:memory:/../test02 4:blkio:/ 3:cpuacct:/ 2:cpu:/ 1:cpuset:/
相対パスのように見えます。
とりあえずここまで。これだけだとすでにマウントされている cgroupfs はそのままの元のディレクトリ階層で見えるので、/proc/$PID/cgroup だけ見え方が変わっても意味がないような気がしますが、改めて cgroupfs のマウントを試すとエラーになりますし、どうするものなのかちょっとまだ見えてないので、またわかれば続編を書く予定です。
(続くかも?)
[Linux][Kernel][Security] User Namespace と Overlayfs と CVE-2015-8660
単なるメモです。
aufs-users ML に流れた、Overlayfs と User Namespace(userns) を併せて使った時の脆弱性のお話:
脆弱性の内容は
これに関連する脆弱性として CVE-2015-8660 があるようで、これはすでに修正済みで、上記に書かれた脆弱性もこれで影響なくなるらしい。
aufs で userns は aufs を使った一般ユーザ権限で起動するコンテナ - TenForwardの日記 のあたりの話で、普段から allow_userns=1 で使ってるので、少し興味をそそられたので試してみました。
ただ、上記に書かれている脆弱性ですが、そもそも vanilla kernel だと userns 内の特権ユーザでも overlayfs のマウントはできないので、ここに書かれている userns 内で Overlayfs マウントして悪いことする、ってのは無理なような気がするので、パッチを当てて userns 内で Overlayfs マウントができるようにしている Ubuntu 特有の話に思えるけど、他にできるようにしてるディストリビューションあるのかな?
Plamo でも Ubuntu を真似して、userns 内で overlayfs マウント可能にしてます。こんなパッチ:
diff -uNr linux-4.2/fs/overlayfs/super.c linux-4.2-olfs/fs/overlayfs/super.c --- linux-4.2/fs/overlayfs/super.c 2015-08-31 03:34:09.000000000 +0900 +++ linux-4.2-olfs/fs/overlayfs/super.c 2015-09-02 16:09:24.339937219 +0900 @@ -1097,6 +1097,7 @@ .name = "overlay", .mount = ovl_mount, .kill_sb = kill_anon_super, + .fs_flags = FS_USERNS_MOUNT, }; MODULE_ALIAS_FS("overlay");
(参考:overlayfs と LXC 非特権コンテナの snapshot によるクローン - TenForwardの日記の「Plamo 5.2の非特権コンテナのclone」の項)
とりあえず aufs-users ML にあったパッチを当てて試してみました。aufs では成功しないけど…
試した環境は
- Kernel 4.2.3 に aufs パッチと前述の userns 内で overlayfs マウント可能にするパッチを当てた環境(脆弱性あり)
- Kernel 4.4 に aufs パッチと前述の userns 内で overlayfs マウント可能にするパッチを当てた環境(脆弱性なし)
Kernel 4.2.3 の Overlayfs
$ ./UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash Setting uid map in /proc/3749/uid_map Setting gid map in /proc/3749/gid_map euid: 65534, egid: 65534 euid: 0, egid: 0 overlayfs Namespace helper waiting for modification completion Namespace part completed
成功してるらしいけど、これだけだと何がなんだか謎なので、gdb でステップ実行しながら、Overlayfs マウントして su を chmod したあたりで止めてチェックしてみました。
$ gdb ./UserNamespaceOverlayfsSetuidWriteExec (gdb) set follow-fork-mode child (gdb) b 63 Breakpoint 1 at 0x400fb5: file UserNamespaceOverlayfsSetuidWriteExec.c, line 63. (gdb) run -- /bin/bash Starting program: /home/karma/userns/UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [New process 3236] Setting uid map in /proc/3236/uid_map Setting gid map in /proc/3236/gid_map euid: 0, egid: 0 euid: 0, egid: 0 [Switching to process 3236] Breakpoint 1, childFunc (arg=0x7fffffffe668) at UserNamespaceOverlayfsSetuidWriteExec.c:63 63 result=chmod("su", 04777); (gdb) n 64 if(result) { (gdb) p result $1 = 0 (gdb)
ここで止めます。別シェルで
$ sudo nsenter -t 3908 -m -U plamo64:/# ls -l /tmp/x/bin/su -rwsrwxrwx 1 nobody nogroup 161 1月 15 18:38 /tmp/x/bin/su plamo64:/# ls -l /tmp/x/over/su -rwsrwxrwx 1 nobody nogroup 161 1月 15 18:38 /tmp/x/over/su
ここで su のパーミッションが変わっているのがマズいんだと思う。
Kernel 4.4 の Overlayfs
対策済みなカーネルでやるとこんな風に。
$ ./UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash Setting uid map in /proc/4960/uid_map euid: 65534, egid: 65534 Setting gid map in /proc/4960/gid_map euid: 0, egid: 0 overlayfs Mode change failed Failed to open /proc/4960/cwd/su, error No such file or directory
同じように gdb から起動して chmod のあとで止めてみます。
$ gdb ./UserNamespaceOverlayfsSetuidWriteExec (gdb) set follow-fork-mode child (gdb) b 63 Breakpoint 1 at 0x400ff1: file UserNamespaceOverlayfsSetuidWriteExec.c, line 63. (gdb) set env TRY_AUFS=1 (gdb) run -- /bin/bash Starting program: /home/karma/userns/UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [New process 3215] Setting uid map in /proc/3215/uid_map Setting gid map in /proc/3215/gid_map euid: 0, egid: 0 euid: 0, egid: 0 aufs [Switching to process 3215] Breakpoint 1, childFunc (arg=0x7fffffffe668) at UserNamespaceOverlayfsSetuidWriteExec.c:63 63 result=chmod("su", 04777); (gdb) n Failed to open /proc/3215/cwd/su, error Permission denied 64 if(result) { (gdb) p result $1 = -1 (gdb)
上記で失敗しているのはわかるんだけど、ここで同じく別シェルを開いて一応確認。
$ sudo nsenter -t 3215 -m -U plamo64:/# ls -l /tmp/x/bin/su -rwsr-xr-x 1 nobody nogroup 37400 1月 22 2015 /tmp/x/bin/su plamo64:/# ls -l /tmp/x/over/su -rwsr-xr-x 1 nobody nogroup 37400 1月 22 2015 /tmp/x/over/su
Kernel 4.2.3 の aufs (allow_userns=1)
allow_userns=1 で実行。
$ TRY_AUFS=1 ./UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash Setting uid map in /proc/3321/uid_map Setting gid map in /proc/3321/gid_map euid: 0, egid: 0 euid: 0, egid: 0 aufs Mode change failed Failed to open /proc/3321/cwd/su, error Permission denied
$ gdb ./UserNamespaceOverlayfsSetuidWriteExec (gdb) set follow-fork-mode child (gdb) set env TRY_AUFS=1 (gdb) b 63 Breakpoint 1 at 0x400ff1: file UserNamespaceOverlayfsSetuidWriteExec.c, line 63. (gdb) run -- /bin/bash Starting program: /home/karma/userns/UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash [New process 3399] Setting uid map in /proc/3399/uid_map Setting gid map in /proc/3399/gid_map euid: 0, egid: 0 euid: 0, egid: 0 aufs [Switching to process 3399] Breakpoint 1, childFunc (arg=0x7fffffffe668) at UserNamespaceOverlayfsSetuidWriteExec.c:63 63 result=chmod("su", 04777); (gdb) n 64 if(result) { (gdb) p result $1 = -1 (gdb) n 65 fprintf(stderr, "Mode change failed\n");
Kernel 4.2.3 の aufs (allow_userns=0)
allow_userns=0 にすると、そもそも Userns 内のユーザはマウントできないので
$ TRY_AUFS=1 ./UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash Setting uid map in /proc/3245/uid_map Setting gid map in /proc/3245/gid_map euid: 0, egid: 0 euid: 0, egid: 0 aufs Overlay mounting failed: 1 (Operation not permitted)
Kernel 4.4.0 の aufs
4.2.3 と同じような動き。
$ TRY_AUFS=1 ./UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash Setting uid map in /proc/3202/uid_map Setting gid map in /proc/3202/gid_map euid: 0, egid: 65534 euid: 0, egid: 0 aufs Mode change failed Failed to open /proc/3202/cwd/su, error Permission denied
$ gdb ./UserNamespaceOverlayfsSetuidWriteExec (gdb) set follow-fork-mode child (gdb) b 63 Breakpoint 1 at 0x400ff1: file UserNamespaceOverlayfsSetuidWriteExec.c, line 63. (gdb) set env TRY_AUFS=1 (gdb) run -- /bin/bash Starting program: /home/karma/userns/UserNamespaceOverlayfsSetuidWriteExec -- /bin/bash warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [New process 3215] Setting uid map in /proc/3215/uid_map Setting gid map in /proc/3215/gid_map euid: 0, egid: 0 euid: 0, egid: 0 aufs [Switching to process 3215] Breakpoint 1, childFunc (arg=0x7fffffffe668) at UserNamespaceOverlayfsSetuidWriteExec.c:63 63 result=chmod("su", 04777); (gdb) n Failed to open /proc/3215/cwd/su, error Permission denied 64 if(result) { (gdb) p result $1 = -1 (gdb) n 65 fprintf(stderr, "Mode change failed\n"); (gdb)
(2016-01-20 追記) http://lwn.net/Articles/671641/ にこの件が載っていますね。