実験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
その後、名前空間内でget new shellを実行しましたが、新しく作成されたmount名前空間内ではumountをunshare -mU --map-root-user --propagation private /usr/bin/zsh実行できず、まだマウントされていないというメッセージだけが表示されました。新しく作成されたマウント名前空間を確認できますが、プライベートマウントを提供します。/tmp/IMJUSTTMPumountcat /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つの実験で正確に何が起こったのかを説明できる人はいますか？マウントネームスペース内でのマウントとマウント解除の詳細なカーネルの動作について言及するドキュメントはありますか？ 「スーパーブロックオーナー」とは何ですか？このカーネルはコミットします。そしてユーザーの名前空間内でマウント "/"をバインドできないのはなぜですか？？
ベストアンサー1
例:-)。ここには3つの異なる点があります。
umount: /tmp/IMJUSTTMP: not mounted実験1：umount /tmp/IMJUSTTMP名前空間を入力しようとするとエラーが発生するのはなぜですか？
[...]
マウントネームスペースの制限
名前空間のマウントに関しては、次の点に注意してください。
各マウントネームスペースには所有者ユーザーネームスペースがあります。上記のように、新しいマウントネームスペースが作成されると、そのマウントリストは別のマウントネームスペースのマウントリストのコピーに初期化されます。新しいネームスペースとマウントリストがコピーされたネームスペースが異なるユーザーネームスペースに属する場合、新しいマウントネームスペースは権限が低いと見なされます。
権限の低いマウントネームスペースが作成されると、共有マウントがスレーブマウントに縮小されます。これにより、特権の低いインストール名前空間で行われたマッピングは、特権の高いインストール名前空間に伝播されません。
特権の高いマウントネームスペースのマウントは単一の単位で一緒にロックされており、特権の低いマウントネームスペースから分離することはできません。 (unshare(2) CLONE_NEWNS ジョブは、元のマウント名前空間のすべてのマウントを単一単位で伝播し、マウント名前空間間で伝播される再帰マウントは単一単位で伝播します。
[...]
実験2：overlayfsの作成にも失敗しました。
権限のないファイルシステムマウント、2018年版 [LWN.net]
一般ユーザーが安全に取り付け作業を実行できるようにすることは新しいものではありません。貯水温網パッチセットで覆う2008年に戻ります。これはマージされていませんが、無許可のマウントを許可しようとしました。拾った2015年、Eric Biederman（および他の人、特にSeth Forshee）は、ユーザーの名前空間がファイルシステムのマウントを実行できるようにすることを真剣に検討し始めました。これ予備作業 2016年に4.8カーネルにマージされましたが、その問題に対する完全な解決策ではないことが知られているので、ほとんどのファイルシステムはまだ初期名前空間に対する権限を持つユーザーのみをマウントできます。。
2008年のLWNの記事では、「ユーザーネームスペース内での使用に安全」が確認されたファイルシステムが.とマークされており、簡単に検索できると明示されてFS_USERNS_MOUNTいます。許可されるファイルシステム。
このマークに注意してくださいカーネルバージョン5.11のOverlayFSに追加されました。これにより、権限のあるユーザーとマウントの名前空間内で1つをマウントできるようになりました。
このカーネルコミットで言及されている「スーパーブロックの所有者」とは何ですか？
リンクされたカーネルコミットのソースコードによると、各スーパーブロックは特定のユーザーネームスペースが所有していると見なされます。所有者は、元のスーパーブロックを作成したユーザーの名前空間です。