アプリケーションから特定のインストール名前空間に一時的に「移行」して内容を確認し、アプリケーションを起動したインストール名前空間に戻してから、/proc別のインストール名前空間に切り替える必要があります。
アプリケーションは、「root」マウントネームスペースを使用してrootユーザーとして起動します（ここには2つの異なるルートコンセプトがあります！）。
フードの下からsetns()前後に切り替えることができます。最も重要なのはZalandoを使用することですnsenter Pythonライブラリ。このライブラリを使用すると、後で/proc/self/ns/[nstype]再度切り替えるために使用されるfdを最初に開いて、特定の名前空間に「入力」できます。次に、ファイルシステムの名前空間パスを取得してfdを開きますsetns(fd, 0)。次に、最初のfdを使用して元の名前空間に再接続してsetns()再利用します。これはネットワークネームスペースに適しています。
ただし、ジャンプマウント名前空間の場合は、離れる前に同じマウント名前空間を再入力しようとすると失敗します。ここでジャンプするということは、私のアプリケーションがマウントネームスペースに入り、いくつかのタスクを実行し、元のマウントネームスペースに戻り、マウントネームスペースに戻してから再度切り替えることを意味します。
とにかく問題はコンテナ内のコンテナにあるようです。
マウントネームスペースの切り替えに制限がありますか？たぶんユーザーの名前空間に関連していますか？これマウントネームスペースのマニュアルページユーザーネームスペースについて説明しましたが、コンテナのマウントネームスペースを作成するときにアクティブになったさまざまなユーザーネームスペースが、そのコンテナマウントロードネームスペースのroot権限を使用してrootユーザーネームスペースに、またはrootユーザーネームスペースから切り替える私のアプリケーションにどのような影響があるのかわかりません。これらのマウントネームスペースに切り替えると、私のアプリケーションは権限を失い、後で失敗しますか？
だから巨人に敬意を表してください。マウントネームスペースホッピングは有害と見なされますか？
ベストアンサー1
おそらく、マニュアルページの最後にこの小さな印刷物があります。設定(2)私のジレンマの鍵は次のとおりです。
マウントネームスペースを変更するには、呼び出し側は独自のユーザーネームスペースにCAP_SYS_CHROOTおよびCAP_SYS_ADMIN機能とターゲットマウントネームスペースにCAP_SYS_ADMIN機能の両方が必要です。
他のコンテナ内のコンテナのマウントネームスペースに入った後、私のアプリケーション/プロセスで一部のCAPが失われ、マウントネームスペース内にロックされているようです。 s5illはまだ疑問です。ルートインストール名前空間と再接続しようとするとエラー/例外はありません...
トランジションの一般的な使用例は、ターゲットネームスペースに切り替えてから消えますが、もう一度切り替えることはありません。名前空間がマウントされると、戻ってくるライフラインがないように見えます。