☰

インストール名前空間での Pivot_root(".", ".") の奇妙な動作

tag-icon • tag-icon linux mount namespace unshare
インストール名前空間での Pivot_root(

私はコンテナを理解しようとしていますが、LXC開発者が発見したと思われるトリックを偶然見つけました。これはPRを実行しますpivot_root(".", ".")：以前のルートをディレクトリに配置する必要がないように呼び出すことができます。ただし、これによりマウント名前空間が奇妙に機能します。

unshare --user --map-root-user --mount bash -c "
mount --bind containerfs bindmountpoint
cd bindmountpoint
pivot_root . .
# this is fine:
ls -l /
# this is not fine:
ls -l /..
"

ルートマウントネームスペースのルートを指すか、それを介してアクセスされる親.（まだネストしようとしませんでした）！これはnorの親を指すことなく、外部マウントネームスペースのルート/ルートを指します。./../../proc/<any>/cwd/..containerfsbindmountpoint

もう一度これを試みたとき、nsenter --user --preserve-credentials --mount --target=<pid>この新しいプロセスはCWDをルートインストール名前空間のルートに配置しました。

私がいたとき、これは起こりませんでしたpivot_root(".", "oldroot")。この動作は、ファイル記述子または.unmountを介して以前のumount -l /ルートをアンマウントしたときにも消えますumount -l /proc/1/cwd。

pivot_rootまた、現在のプロセスに対する保証のみが提供されているため、カスタムCプログラムから一連のシステムコールを試みました。したがって、すべての操作が同じプロセスで実行されます。動作は、CLI ツールを使用して上記のマルチプロセスステップと同じです。

5.3 カーネルでテストされました。

走るとどうなりますかpivot_root(".", ".")？

ベストアンサー1

pivot_root(new_root, put_old)呼び出しプロセスの前のルートディレクトリ（マウントのルートである必要があります）をその場所に移動してput_old配置します。new_root次に、現在のディレクトリと各プロセスのルートを前のルートディレクトリに設定しますnew_root。

したがって、pivot_root(".", ".")新しいルートの後に、古いルートがその上にインストールされます。

他のディレクトリがマウントされたディレクトリとして解釈されるたびに、..実際にはその上にマウントされたディレクトリとして解釈されます。..これは、ファイルシステムのルートディレクトリを除いて、パスナビゲーションに特別な処理がなく、ディスクに格納されているディレクトリエントリとして実装されている歴史的なUnixおよびLinuxの動作と一致します。

これはマウントネームスペースエスケープではありません。

おすすめ記事