web-dev-qa-db-ja.com

新しく作成されたマウント名前空間内の継承されたマウントのマウントとアンマウントについて

実験1

名前空間の外部から、cat /proc/self/mountinfo

291 34 0:37 / /tmp/IMJUSTTMP rw,relatime shared:152 - tmpfs tmpfs rw,size=102400k
34 23 0:32 / /tmp rw,nosuid,nodev shared:16 - tmpfs tmpfs rw

次に、unshare -mU --map-root-user --propagation private /usr/bin/zshを実行して、名前空間内に新しいシェルを取得しますが、新しく作成されたマウント名前空間内では、/tmp/IMJUSTTMPumountをアンマウントできません。マウントされていないことを通知するだけです。新しく作成されたマウント名前空間はcat /proc/self/mountinfoで確認できますが、これによりプライベートマウントが提供されます

290 263 0:32 / /tmp rw,nosuid,nodev - tmpfs tmpfs rw
302 290 0:37 / /tmp/IMJUSTTMP rw,relatime - tmpfs tmpfs rw,size=102400k

それでは、名前空間内でumount: /tmp/IMJUSTTMP: not mounted.をアンマウントしようとすると、なぜ/tmp/IMJUSTTMPを取得するのですか?

5.0.9-Arch1-1-Archをkernel.unprivileged_userns_clone = 1で使用しています。

実験2

unshare -mU --map-root-user --propagation private /usr/bin/zshの後、overlayfsを作成しようとしても失敗します。

mkdir -p /tmp/IMJUSTTMP/work
mkdir /tmp/IMJUSTTEST
mount -t tmpfs -o size=100m tmpfs /tmp/IMJUSTTMP
mount -t tmpfs -o size=200M tmpfs /tmp/IMJUSTTEST

以下はすべて名前空間内にpermission deniedを取得しますが、すべて期待どおりに成功します。

mount -t overlay -o "lowerdir=/home/xtricman,upperdir=/tmp/IMJUSTTMP/,workdir=/tmp/IMJUSTTMP/work" overlay /home/xtricman
mount -t overlay -o "lowerdir=/tmp/IMJUSTTEST,upperdir=/tmp/IMJUSTTMP,workdir=/tmp/IMJUSTTMP/work" overlay /mnt

私の大まかな推測

これらの2つの質問を見つけました ユーザー名前空間内で、マウントしたファイルシステムを再マウントできないのはなぜですか? および ユーザー内で "/"をバインドマウントできないのはなぜですか?)名前空間?/tmp/IMJUSTTMP/tmpマウントを継承しているため、新しく作成したマウント名前空間の所有ユーザー名前空間ですべての機能を取得しても、それらをアンマウントできないようです。 。

質問

誰かが2つの実験の何が起こっているのかを正確に説明できますか?マウント名前空間内でのマウントとアンマウントの詳細なカーネル動作について言及しているドキュメントはありますか? このカーネルコミット および ユーザー名前空間内に「/」をバインドマウントできないのはなぜですか? で説明されている「スーパーブロック所有者」とは何ですか?

はい :-)。ここには3つの明確なポイントがあります。

実験1:なぜ私はumount: /tmp/IMJUSTTMP: not mountedしようとするとumount /tmp/IMJUSTTMP名前空間内?

http://man7.org/linux/man-pages/man7/mount_namespaces.7.html

マウント名前空間の制限

マウント名前空間に関して、次の点に注意してください。

  • マウント名前空間には、所有者ユーザー名前空間があります。所有者ユーザー名前空間が親マウント名前空間の所有者ユーザー名前空間と異なるマウント名空間は、特権の少ないマウント名前空間と見なされます。

  • 特権の少ないマウント名前空間を作成すると、共有マウントはスレーブマウントになります。 (共有マウントとスレーブマウントについては、以下で説明します。)これにより、特権の低いマウント名前空間で実行されたマッピングが、特権の高いマウント名前空間に伝播されなくなります。

  • より特権のあるマウントから単一のユニットとして提供されるマウントは一緒にロックされ、特権の低いマウント名前空間で分離することはできません。 (unshare(2)CLONE_NEWNS操作は、元のマウント名からのすべてのマウントを単一のユニットとして伝達し、マウント名前空間間で伝播する再帰的マウントは単一のユニットとして伝播します。)

  • Mount(2)フラグMS_RDONLY、MS_NOSUID、MS_NOEXEC、および「atime」フラグ(MS_NOATIME、MS_NODIRATIME、MS_RELATIME)の設定は、特権の高いマウント名前空間から特権の低いマウント名前空間に伝播されるとロックされます。特権の少ないマウント名前空間。

実験2:overlayfsを作成しようとしても失敗します

マウント操作を通常のユーザーにとって安全にする試みは目新しいことではありません。 LWN 1つのパッチセットをカバー 2008年に戻った。その作業はマージされなかったが、非特権マウントを許可するための努力 ピックアップ 2015年、Eric Biederman(他の人と一緒にSeth特にForshee)は、ユーザーの名前空間がファイルシステムのマウントを実行できるようにすることに真剣に取り組んでいます。 初期作業 は2016年に4.8カーネル用にマージされましたが、問題の完全な解決策ではないことがわかっていたため、 ほとんどのファイルシステムは、最初の名前空間で特権を与えられているユーザーのみがマウントできます。

非特権ファイルシステムマウント、2018年版 、LWN.net

2008年のLWNの記事によると、「ユーザー名前空間内で安全に使用できる」と確認されたファイルシステムにはFS_USERNS_MOUNT。したがって、簡単に検索して 許可されているファイルシステム を見つけることができます。

このカーネルコミットで言及されている「スーパーブロック所有者」と、「ユーザー名前空間内で「/」をバインドマウントできないのはなぜですか?」という質問とは何ですか? ?

リンク先のカーネルコミットのソースコードは、各スーパーブロックが特定のユーザー名前空間によって所有されていると見なされることを示しています。所有者は、最初にスーパーブロックを作成したユーザー名前空間です。

2
sourcejedi