- 他のインストール名前空間のファイルとディレクトリには引き続きアクセスできます。もしあなたは彼らの参考資料を持っています。ただし、現在は、実行中の名前空間でない限り、名前空間をマウントするマウントを操作（またはリスト）することはできません。
- 分離されたマウント（
umount -l）はマウントネームスペースがないと見なされるため、操作（またはサブマウントのリスト）は許可されません。
たとえば、セキュリティ上の理由から、ネームスペースAPIにポイント1（またはポイント2）の制限は重要ですか？既存のソフトウェアはそれに依存していますか？
そうでなければ、Linuxコードからポイント2（およびポイント1）の制限を削除するのは難しいでしょうか？つまり、そうするための主な障害は何ですか？
同期：別のマウントツリーを作成できる場合はchrootその中に入ることができ、マウントネームスペースは基本的に重複していると思います。ただし、他の種類のLinuxネームスペースにはまだある程度の利便性/一貫性があります。
ベストアンサー1
活用できる別個のマウントツリーを構築できれば、
chrootマウントネームスペースは基本的に重複していると思います。ただし、他の種類のLinuxネームスペースにはまだある程度の利便性/一貫性があります。
私の考えには（少なくとも）重要な点を逃しているようだ。
名前空間の特徴の1つは、ユーザーの名前空間に関連付けられていることです。ユーザーの名前空間は、CAP_SYS_ADMINやCAP_NET_RAWなどの「スーパーユーザー」機能を分離します。たとえば、CAP_NET_RAWは、ユーザーに属するネットワーク名前空間が所有している場合、ネットワークデバイスのネイティブネットワークパケットへのアクセスを許可できます。
CAP_SYS_ADMINを使用すると、ユーザーに属するマウントネームスペースを操作できます。現在の制限は、必要なものよりも制限的ですが、いくつかの制限が必要です。ユーザーの名前空間がCAP_MOUNTを分離できるように、マウントツリーを名前空間にバインドする必要があります。
名前空間のマウントの代替を実装することは、ユーザーの名前空間では機能しないため、あまり意味がないようです。