5.11 で追加された OverlayFS の非特権マウント（1） - TenForward
5.11 カーネルで overlayfs に大きな変更があったようで、久々にカーネルの新しい機能を試してみました。 とは言っても、結果だけ言うとすぐに終わってしまうので、すごいことをやったように見せかけるために、復習したりして順に説明していきましょう。時間のない方は最後の方だけ見れば良いです。 OverlayFS とは Union Filesystem の実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーを構成できます。Docker なんかではおなじみの機能ですね。おなじみの機能とはいえ、実際に直接マウントして動きを見たことがない方も多いかと思います。そこでまずは動きを簡単に見てみましょう。 重ね合わせるということで、下層側ディレクトリ、上層側ディレクトリを重ね合わせて、マウントポイント以下に見せます。他にワーク用の workdir として指定するディレクトリが必要です。 次
マウントプロパゲーション（1）〜 shared mount 〜 - TenForward
完全に私個人が理解するための資料です。間違いの指摘は大歓迎です。 2001 年に 2.4 kernel でバインド（bind）マウントが、2002 年の 2.4.19 で mount namespace が導入されました。ただ、ユースケースによっては mount namespace が行う分離は徹底しているので、もう少しマウントが共有されても良いシーンがあったようで、shared マウントなどのマウントプロパゲーションの考え方が 2.6.15（2006 年 1 月）で導入されました。 そのマウントプロパゲーションについてまとめていきます。 説明中の「サブマウント」とは、あるマウントポイントがあったとして、そのツリー配下で行われるマウント処理のことを指すとします。例えば、ホストで/dev/sda1というデバイスをルート/にマウントします。その配下の/homeに/dev/sda2をマウントした
unshare コマンドがマウントプロパゲーションをまともに扱うような変更を入れていた - TenForward
全国10万人の unshare でコンテナを作るのが好きなコンテナマニアの方々が systemd のおかげで余計な処理をさせられてたのですが、いつの間にか unshare(1) コマンド側であるべき姿に戻す処理が追加されていたというお話です。 結論 回りくどい話が嫌いな方も多いかと思うので、最初に結論を簡潔にまとめときます。ここだけ読めば結論はわかります。 前提として、 kernel デフォルトではマウントプロパゲーションは private 8 年ほど前に systemd で起動時に shared にするように処理が追加されてる このため unshare --mount で新たに Mount Namespace を作って、その中でマウント処理を行ってもホスト側でもそのマウントが見えるようになっていた というような状態でした。ところが unshare --mount を実行したら当然 Nam
LXDのシステムコールインターセプション機能を試す（マウント編）（2） - TenForward
先のエントリーでは、コンテナ内から 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
LXDのシステムコールインターセプション機能を試す（解決編） - TenForward
3 回シリーズになるとは思ってなかったこのシリーズ、ついに解決編です。 tenforward.hatenablog.com 1 度目の mknod は成功するものの、なぜか続けて mknod を実行すると失敗してしまうという謎のトラブル。ふと、LXC のコミットログを眺めていると seccomp 関連の修正があり、見てみると簡単な修正ですが、コミットログと修正内容を見てピンと来ました。 それがこれです。 github.com 新しいカーネルではバッファーをゼロクリアしておく必要があるとのこと。これだと 1 度実行して成功しても、そのバッファに前のデータが残っていたらエラーになりそう！ということで試すとバッチリ成功しました。 これだけだとなんなので、今回のシステムコールインターセプション機能についてまとめておきましょう。 システムコールインターセプション機能 5.0 kernel で Add
ケーパビリティバウンディングセット - TenForward
今更感たっぷりな話題ですが、今頃ケーパビリティについて調べてます。これまで何度も調べてはよくわからなくて挫折を繰り返してるとこです。 ケーパビリティについては udzura.hatenablog.jp が詳しいのですが、「ケーパビリティバウンディングセット」の部分だけはちょっと良くわからんのですよね…（偉そうにスミマセン）。 そして、udzura さんのブログも Ambient については記載がまだありませんので、Ambient についてはこちら、 nojima.hatenablog.com 現時点では日本語ではここしかありません（勉強させてもらいました）。 そういうわけで、ケーパビリティバウンディングセットについて調べていてもなんかよくわからんので調べながらメモ。メモなので脈絡なかったり、急になんの前提もなく何かが出てくるかもしれません。 基本はマニュアル capabilities(7)
ping コマンドの file capability（2） - TenForward
（理解が不十分なので間違っている所があれば優しく教えてください） さて、ping コマンドの file capability（1） - TenForward で紹介したように ping コマンドの File capability は Permitted のみが有効になっていて、Effective ビットはオン（+e）になっていません。これで ping が実行できる理由は説明したとおりですが、+e が設定されていない理由は「不要だから」というだけの理由ではありません。 「なんで +e ないんだろう？」とつぶやいていると WhiteAnthrax さんが調べて教えてくれました！ありがとうございます！ これは www.projectatomic.io に書かれている通りです。Docker コマンド内の ping コマンドの実行で問題が起こるからということです。 まず Docker コンテナでは、
ShiftFS ふたたび 〜 Ubuntu 19.04で導入された ShiftFS を試してみた - TenForward
ちょうど 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
Linux 4.14 で導入された cpuset の cgroup v2 mode - TenForward
（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 で表示され
af-graft を LXC コンテナで試してみた - TenForward
Twitter でコンテナ用の面白い仕組みを見つけたので試してみました。中身ほぼゼロです。 コンテナの中で開いたsocketがhost stackに生えるという不思議socketです。論文はこちら https://t.co/YyP67mDPt2 実装はこちら https://t.co/IaKO5RFfkG— upa (@upaa) 24 July 2018 論文も公開されているようですね。 https://dl.acm.org/citation.cfm?id=3230723 README を見る限りは普通に LXC で使えそうなのでロクにドキュメント読まず（コラ）やってみました。 とりあえず Ubuntu 16.04 ホストを準備します（AWS 上に準備しました）。そして LXC をインストールします。こういうときは LXD でなく設定ファイルちょいちょいといじって起動させられる LXC
Linux 3.14 で net_cls cgroup に追加された netfilter 対応 - TenForward
久々に cgroup 大物新機能に沸いてます! (久々じゃないかw) kernelnewbies の 3.14 ページ に書いてない気がするので危うく見逃す所でした．早速試してみました (カーネル付属文書なぞっただけ :p) 対応するコミットはこちら． netfilter: x_tables: lightweight process control group matching まずは準備をします．追加されたばかりの機能なので準備には時間かかりますよ． :-) まずは NETFILTER_XT_MATCH_CGROUP を "y" か "m" にして 3.14 カーネルを作製します iptables も最新のリリース版 1.4.21 では cgroup 対応機能が実装されていないので git clone して，"next-3.14" ブランチで make します (master でも OK
shiftfs (s_user_ns version) 試してみた - TenForward
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
pivot_root できる条件 - TenForward
ふとしたきっかけで 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 には以下の制限がある: ディレクトリでなければならない。
4.5 カーネルで stable となった cgroup の単一階層構造 cgroup v2 の io コントローラ - TenForward
Control Group v2 以前も少し紹介していましたし、連載でも少し触れましたが、今広く (?) 使われている cgroup は色々問題があって、単一階層構造の cgroup が開発されていました。この辺りは Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForwardの日記 Linux 3.16 から試せる cgroup の単一階層構造 (2) - TenForwardの日記 で紹介しました。 以前は開発中の機能だったため、マウントするときに "__DEVEL__sane_behavior" などというふざけたオプションが必要でした。(^^) この後も順調に (?) 開発はすすみ、4.5 カーネルのリリースでついにこの機能が stable となったようで、"__DEVEL__" というプレフィックスも不要になりましたし、正式な機能で「まともなふ
ip netns コマンドが意外にきめ細やかにコンテナを作ってくれる - TenForward
(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 が消滅してくれ
Linux 3.8 で改良された Namespace 機能と lxc-attach コマンド - TenForward
以前から lxc には lxc-attach というコマンドが含まれていました．このコマンドは OpenVZ やその商用版の Virtuozzo にある vzctl exec というコマンドと同じ目的のもので，コンテナ外のホスト OS 上から直接コンテナ内のコマンドを実行するためのものです．なぜ attach なのかというと，実行しようとするプロセスを既に存在する名前空間 (Namespace) に参加させるためのモノだからですね (コマンド名から動きが想像しにくい気がしますが :p)． このような目的のコマンドはコンテナ環境を運用しようとすると必須のものと言えます．例えばコンテナを起動するのはホスト上から lxc-start コマンドで実行できますが，シャットダウンコマンドはコンテナ内から実行しないといけません (もちろん外から強制終了は可能ですが)．その他，運用の色々な場面でコンテナ外
cgroup なのか cgroups なのか - TenForward
割とどーでもいい話（でも気になってた人多いはずw） 以前、第4回のコンテナ勉強会でも質問が出たのですが、cgroup/cgroups という機能の正式な名称は cgroup なのか cgroups なのか、というのはよくわかりませんでした。 私は、英語って単数・複数をきちんと使い分けるし、cgroup は複数のサブシステム・コントローラが存在するので、海外の人は "cgroups" と複数形で使うんだろうなあと思ってました。機能自体を指しているのか、コントローラ群を含めて指しているのかって、曖昧な文脈も多いですし。 しかし、この論争にもついにピリオドが打たれました。カーネル付属文書の cgroup-v2.txt をご覧ください。 "cgroup" stands for "control group" and is never capitalized. The singular form i
Linux 3.8 の User Namespace 機能 (1) - TenForward
コンテナを実現するのにカーネルに必要な機能としては大きく分けて 名前空間 リソース制限 があります． リソース制限は cgroup として実装されています (ここではこの話は置いときます)． 名前空間は，その対象となる空間と他の空間を分ける機能を持っています．コンテナを作る場合，それぞれの空間で独立した uid/gid やネットワークインターフェースが存在しなければいけませんので，その機能を実現しています．既に Linux Kernel には色々な名前空間が実装されており，未実装でコンテナを安全に使うために必須と言われていたのが User Namespace (ユーザ名前空間) です．この実装は徐々に実装されてきていましたが，影響範囲が大きく，実装も難しいため実現していませんでしたが，ようやく kernel 3.8 で実装が完了するようです． 今までもコンテナごとに /etc/passwd
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
