実験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/IMJUSTTMP
、umount
をアンマウントできません。マウントされていないことを通知するだけです。新しく作成されたマウント名前空間は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つの明確なポイントがあります。
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)の設定は、特権の高いマウント名前空間から特権の低いマウント名前空間に伝播されるとロックされます。特権の少ないマウント名前空間。
マウント操作を通常のユーザーにとって安全にする試みは目新しいことではありません。 LWN 1つのパッチセットをカバー 2008年に戻った。その作業はマージされなかったが、非特権マウントを許可するための努力 ピックアップ 2015年、Eric Biederman(他の人と一緒にSeth特にForshee)は、ユーザーの名前空間がファイルシステムのマウントを実行できるようにすることに真剣に取り組んでいます。 初期作業 は2016年に4.8カーネル用にマージされましたが、問題の完全な解決策ではないことがわかっていたため、 ほとんどのファイルシステムは、最初の名前空間で特権を与えられているユーザーのみがマウントできます。。
非特権ファイルシステムマウント、2018年版 、LWN.net
2008年のLWNの記事によると、「ユーザー名前空間内で安全に使用できる」と確認されたファイルシステムにはFS_USERNS_MOUNT
。したがって、簡単に検索して 許可されているファイルシステム を見つけることができます。
リンク先のカーネルコミットのソースコードは、各スーパーブロックが特定のユーザー名前空間によって所有されていると見なされることを示しています。所有者は、最初にスーパーブロックを作成したユーザー名前空間です。