はてなブックマーク

この記事は Linux Advent Calendar 2023 5 日目の記事です。前日は @mnishiguchi さんの「Linux US キーボードの CapsLock を Ctrl に変更する方法」ですね。私は setxkbmap でやってます。 さて、このブログ久々の技術的な内容です。Linux カーネルが持つ cgroup という機能のうち、タスクやタスクのグループに対して CPU の帯域制限（単位時間内にどれだけ CPU が使えるか）を設定できる機能のコードを少し追ってみたお話です。あとで紹介する gihyo.jp さんに掲載している記事とあわせて読んでいただけるとよりうれしいです。 もう 4 年くらいまえのブログなんですが、Indeed さんのエンジニアリングブログのこの 2 つの記事がすばらしいんです。わかりやすい。もう cgroup の CPU コントローラーから使う

私が主に翻訳で関わってきた linuxcontainers.org のプロジェクトであった LXD が、プロジェクトから Canonical 配下に移動しました。 MLや公式ページでアナウンスされています。 LXD is no longer part of the Linux Containers project （Mailing Listのアナウンス） LXD is now under Canonical （公式ページのアナウンス） LXD は Canonical の傘下に入りました （アナウンスの日本語訳） While the team behind Linux Containers regrets that decision ここの表現は何か微妙な表現になってる気がしますね。 これまでプロジェクトを引っ張ってきた Stéphane Graber さんの Canonical 社からの退

5.11 カーネルで overlayfs に大きな変更があったようで、久々にカーネルの新しい機能を試してみました。 とは言っても、結果だけ言うとすぐに終わってしまうので、すごいことをやったように見せかけるために、復習したりして順に説明していきましょう。時間のない方は最後の方だけ見れば良いです。 OverlayFS とは Union Filesystem の実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーを構成できます。Docker なんかではおなじみの機能ですね。おなじみの機能とはいえ、実際に直接マウントして動きを見たことがない方も多いかと思います。そこでまずは動きを簡単に見てみましょう。 重ね合わせるということで、下層側ディレクトリ、上層側ディレクトリを重ね合わせて、マウントポイント以下に見せます。他にワーク用の workdir として指定するディレクトリが必要です。 次

これまでの続きです。 マウントプロパゲーション（1）〜 shared mount 〜 - TenForward マウントプロパゲーション（2）〜 private mount 〜 - TenForward マウントプロパゲーション（3）〜 slave mount 〜 - TenForward マウントプロパゲーション（4）〜 unbindable mount 〜 - TenForward マウントプロパゲーション（5）〜 mountinfoファイル 〜 - TenForward これまでと同様に完全に私個人が理解するための資料です。間違いの指摘は大歓迎です。 前回書ききれなかった /proc/[PID]/mountinfo ファイルのエントリーのお話です。 unbindableの場合 unbindableを指定した場合は次のようなエントリになります。 369 31 252:2 /root/t

全国10万人の unshare でコンテナを作るのが好きなコンテナマニアの方々が systemd のおかげで余計な処理をさせられてたのですが、いつの間にか unshare(1) コマンド側であるべき姿に戻す処理が追加されていたというお話です。 結論 回りくどい話が嫌いな方も多いかと思うので、最初に結論を簡潔にまとめときます。ここだけ読めば結論はわかります。 前提として、 kernel デフォルトではマウントプロパゲーションは private 8 年ほど前に systemd で起動時に shared にするように処理が追加されてる このため unshare --mount で新たに Mount Namespace を作って、その中でマウント処理を行ってもホスト側でもそのマウントが見えるようになっていた というような状態でした。ところが unshare --mount を実行したら当然 Nam

先のエントリーでは、コンテナ内から ext4 ファイルシステムのマウントができたのですが、実は security.syscalls.intercept.mount.shift という設定が効いていないようで、そこで時間切れでした（どこがうまく行ってないか書いてませんでしたが）。 tenforward.hatenablog.com そこで Ubuntu 20.04 もリリースされたことですし、もう一度試してみましょう。 前回のおさらい 前回と同様に /dev/vdb というディスクが存在し、パーティションをひとつだけ作成し、ext4 で mkfs しています。テストのために事前にホスト側でマウントし、testfile というファイルをひとつだけ作ってあります。 $ ls -l /mnt/ total 16 drwx------ 2 root root 16384 Apr 29 07:38 l

3 回シリーズになるとは思ってなかったこのシリーズ、ついに解決編です。 tenforward.hatenablog.com 1 度目の mknod は成功するものの、なぜか続けて mknod を実行すると失敗してしまうという謎のトラブル。ふと、LXC のコミットログを眺めていると seccomp 関連の修正があり、見てみると簡単な修正ですが、コミットログと修正内容を見てピンと来ました。 それがこれです。 github.com 新しいカーネルではバッファーをゼロクリアしておく必要があるとのこと。これだと 1 度実行して成功しても、そのバッファに前のデータが残っていたらエラーになりそう！ということで試すとバッチリ成功しました。 これだけだとなんなので、今回のシステムコールインターセプション機能についてまとめておきましょう。 システムコールインターセプション機能 5.0 kernel で Add

連載の第42回 で ファイルケーパビリティは安全のためにコピーすると設定が外れます。 なんてことを書いてますが、同僚から「Arch Linux でやるとなぜか ping が実行できてしまう」という情報が。確かに Arch でやると実行できてしまいます。 $ lsb_release -d Description: Arch Linux $ cp /usr/bin/ping . $ getcap ./ping $ ./ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 receiv

ちょうど 2 年ほど前、Open Source Summit で話を聞いて ShiftFS について試したことがありました。 tenforward.hatenablog.com その後はとりあえずカーネルにパッチを当てたりはしてましたが、あまり使わないままでした。少し前に gihyo.jp の Ubuntu の記事を読んでいると、 discoのカーネルフリーズが4月4日に迫る中，興味深いパッチが投稿されています。パッチの中身は「ShiftFS」と呼ばれる，コンテナ環境でのセキュリティ機能を提供するためのラッパーファイルシステムです https://gihyo.jp/admin/clip/01/ubuntu-topics/201903/29 なんて書かれています。その後の記事で ShiftFSは， 前回取り上げた後，4月4日に無事にマージに辿り着いています。 https://gihyo.jp

Hosting Casual Talks #5 本題に入る前に、このブログエントリのネタを発表してきた勉強会の感想を。 ホスティング業界に関わるエンジニアが カジュアルに 情報交換をするという、全員発表型の勉強会 "Hosting Casual Talks #5" に参加してきました。飲みながら技術について情報交換できる カジュアルな 勉強会ではありますが、内容が全く カジュアルじゃない!! connpass.com ひとりあたり10 or 15分の LT サイズの時間割り当てなのですが、皆さんちゃんと解決したい問題があり、仮説を立て、検証して、考察すると言ったストーリー性のあるスライドになっていたり、問題を解決するためにコード書きました、こういうの作りましたというような、とても LT サイズに収まるものではなく、全員持ち時間はどこへやら、ガッツリと 6 時間、ガチな内容がひたすら続くなか

（2019-02-23 少し追記しています） 4.14 kernel から cgroup の cpuset コントローラーに cpuset_v2_mode というオプションが使えるようになりました。 しばらく見ないうちに cpuset コントローラーをマウントするとファイルがたくさん増えていますが、このオプションを設定すると、従来からある cpuset.{cpus,mems} ファイルの動きが変わるようです。そしていつの間にか増えている cpuset.effective_{cpus,mems} ファイルと合わせて使って cpuset の制限を行うようです。 このオプションを設定したときの動きが、cgroup v2 の cpuset の動きになるようです（v2 の cpuset は現時点ではまだマージされていません）。 現在使える cpu や memory が effective で表示され

$ lxc version Client version: 3.0.1 Server version: 3.0.1 な環境の Ubuntu 18.04 上で試してます。 以下で何の前提もなく書いてるサブ ID のお話は、私の連載 第16回　Linuxカーネルのコンテナ機能 [6] ─ユーザ名前空間 に書いていますのでそちらをどうぞ。 LXD でコンテナを起動すると、デフォルトでは非特権コンテナが起動します。 $ lxc launch ubuntu:18.04 c1 Creating c1 Starting c1 $ lxc list +------+---------+--------------------+-----------------------------------------------+------------+-----------+ | NAME | STATE |

ここ最近、新バージョンリリース時と、ドキュメント（man pages）に更新があったときに翻訳する以外、新しい機能について全く調査していませんでした。 なんとなく見てると LXC 3.0 が近いようですので、どう変わるのかをまとめてみます。 cgroup ドライバの整理 これまで LXC には cgroup 関連のドライバが 3 つ含まれていました。 cgfs cgmanager cgfsng cgfs ドライバはもっとも古くからあるドライバです。今や cgroup は /sys/fs/cgroup にマウントされますが、昔は特にマウントする場所は決まっておらず、/dev/cgroup にマウントしたり、/cgroup にマウントしたりしていました。どこにマウントされるかわからないファイルシステムを検出するロジックなど、今や不要になったロジックが多く含まれています。 cgfs ドライバの機

ちょっと前にリリースされたカーネルですが、4.10 で overlayfs に変更が入っていましたのでちょっと調べてみました。 Overlayfs についてはこちらをどうぞ (ちょっと古い記事なのでカーネルにマージされる前の仕様も説明しています)。 Linuxで学ぶコンテナ入門 第18回 Linuxカーネルのコンテナ機能［7］ー overlayfs (gihyo.jp) それとコンテナ勉強会のこの発表資料 ちょっとOverlayfsの実装、読んでみました (@akachochinさん) カーネルの変更と準備 4.10の関連するコミットは以下。 ovl: redirect on rename-dir ovl: allow redirect_dir to default to “on” ovl: allow setting max size of redirect ovl: show redi

Open Source Summit Japan 2017 で聞いた話に shiftfs の話があって、興味を持ったので試してみました。この機能の前提機能なんかに関する前提知識に欠けているため、以下には間違いが含まれている可能性が大きいです。是非指摘を頂きたいと思います。試してみただけで内部の処理とかは書いてませんよw 下に関連情報を挙げておきます (こちらを直接見たほうがいいかも)。 Container Interfaces for Storage - Are We There Yet? (Open Source Summit の James Bottomley 氏のスライド) shiftfs: uid/gid shifting filesystem (s_user_ns version) (lwn.net) Unprivileged Build Containers (James Bo

ふとしたきっかけで man 2 pivot_root の制限に疑問を持ったので、雑にカーネルのコードを読んでみたエントリです。かなり雑にみただけなので間違いの指摘を歓迎します。というか指摘を受けるために書いたようなもの😅 pivot_root の使われ方 コンテナを起動して、コンテナイメージの root をコンテナの root に設定する際、chroot を抜けられないように権限を制御したりしながら chroot を使ったりすることがあります。 一方で、LXC や Docker では pivot_root が使われます。chroot は比較的簡単に使えるのに対して、pivot_root はいくつか制限があります。 man 2 pivot_root すると、その制限について説明があります。 new_root および put_old には以下の制限がある: ディレクトリでなければならない。

(2016-07-26: 誤記修正しました "setns -> nsenter") お手軽にシェルスクリプトなんかでコンテナを作る場合の強い味方といえば util-linux の unshare/nsenter コマンド iproute2 の ip netns コマンド が代表的でしょう。"ip netns" は Network Namespace 作ってコマンド実行するだけの単純なコマンドかと思ったら、中では意外に色々細かくやってくれていることがわかったのでちょっと紹介しておきます。 以下は iproute2 4.2.0 で試しています。 /var/run/netns まずよく知られているのが /var/run/netns 以下に Namespace 名のファイルを作ってくれることですね。これは、Namespace 内で動いているプロセスがなくなったら Namespace が消滅してくれ

割とどーでもいい話（でも気になってた人多いはずw） 以前、第4回のコンテナ勉強会でも質問が出たのですが、cgroup/cgroups という機能の正式な名称は cgroup なのか cgroups なのか、というのはよくわかりませんでした。 私は、英語って単数・複数をきちんと使い分けるし、cgroup は複数のサブシステム・コントローラが存在するので、海外の人は "cgroups" と複数形で使うんだろうなあと思ってました。機能自体を指しているのか、コントローラ群を含めて指しているのかって、曖昧な文脈も多いですし。 しかし、この論争にもついにピリオドが打たれました。カーネル付属文書の cgroup-v2.txt をご覧ください。 "cgroup" stands for "control group" and is never capitalized. The singular form i

Control Group v2 以前も少し紹介していましたし、連載でも少し触れましたが、今広く (?) 使われている cgroup は色々問題があって、単一階層構造の cgroup が開発されていました。この辺りは Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForwardの日記 Linux 3.16 から試せる cgroup の単一階層構造 (2) - TenForwardの日記 で紹介しました。 以前は開発中の機能だったため、マウントするときに "__DEVEL__sane_behavior" などというふざけたオプションが必要でした。(^^) この後も順調に (?) 開発はすすみ、4.5 カーネルのリリースでついにこの機能が stable となったようで、"__DEVEL__" というプレフィックスも不要になりましたし、正式な機能で「まともなふ

以前、RHEL6 のころに ns cgroup ってサブシステムが cgroup にありましたが、それとは別のお話。 4.6 カーネルに入る cgroup namespace のお話です (Ubuntu 16.04 のカーネルには入るようです) 。namespace ごとに別の cgroup ツリーが見えるようにするものかな。 軽く試してみました。 準備 (2016-04-12 追記) 今だと 4.6-rc? で試せます とりあえず cgroup namespace の機能が入ったカーネルは https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/ の "2016-03-21/nsroot" というブランチのものを使いました。出来上がったカーネルはこんな $ uname -r 4.5.0-rc1-plam

単なるメモです。 aufs-users ML に流れた、Overlayfs と User Namespace(userns) を併せて使った時の脆弱性のお話： Re: try reproducing this problem? 脆弱性の内容は UserNamespaceOverlayfsSetuidWriteExec これに関連する脆弱性として CVE-2015-8660 があるようで、これはすでに修正済みで、上記に書かれた脆弱性もこれで影響なくなるらしい。 aufs で userns は aufs を使った一般ユーザ権限で起動するコンテナ - TenForwardの日記 のあたりの話で、普段から allow_userns=1 で使ってるので、少し興味をそそられたので試してみました。 ただ、上記に書かれている脆弱性ですが、そもそも vanilla kernel だと userns 内の特権

連載書いたり、勉強会で発表したりしているとなかなかブログが更新できませんね。久々の更新です。 これを書いている時点では Linux カーネルの 4.3-rc1 がリリースされていますが、久々に cgroup に新しいコントローラが追加されそうですね。 pids.txt 説明が不要なほどシンプルで分かりやすいです。このブログエントリ読まなくても使えるはず。:-) 軽く使ってみました。大体は上記ドキュメントに沿って試してるだけです。 カーネル カーネルの config では Cgroup 関連の設定以下に "PIDs cgroup subsystem" という項目が新設されているので、ここを有効にしてカーネルを作成するだけです。 General setup ---> Control Group support ---> [*] PIDs cgroup subsystem起動すると /proc/

これはだいぶ前に書いたエントリです。MINCS作者による最新の解説があるのでそちらもご覧ください。 (2016-11-21追記) コンテナは使いたいけど、たくさんコンテナを起動すると結局それぞれのコンテナに対するセキュリティアップデートなどのメンテナンスは必要だし、コンテナ内独自のプログラムやライブラリ以外はホストと共有したいよね、って話が出てきたりします。みんな考えることは同じで、bind mount を使えば良いよね、って話はでてきてました。 こないだもブログで紹介した kazuho さんの jailing 私が LXC でも結構簡単にできるよ、っていう提案を兼ねて作った lxc-bind こないだのLinuxConでもDockerでたくさんのオプションを並べて、色々工夫して bind mount を使ってやってる発表もありました (Using Docker for existing