私のファイル サーバーには、/exports の下に共有データを持つ大きなパーティションが 1 つだけあります。そのため、古いスタイルの NFSv3 エクスポートを使用していました。
/exports/home 192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
そこで、NFSv4 スタイルに切り替えることにし、次のように変更しました。
/exports 192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home 192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc 192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.
次に、マウント コマンドを exclude に変更しました/exports
。確かに/etc
マウントできませんでした (エラーは発生しませんでしたが、中断されるまでロックされていました)。ただし、予想どおり、 の/exports
ACL は下位に継承され、すべての共有は読み取り専用になり、ルートはどこでも押しつぶされました。
また、ACL を/exports/root
単一のマシンに変更してみましたが、違いはありませんでした。
したがって、そのような識別子を決定できないファイルシステムに一意の識別子を提供できること以外に、次のようにエクスポート ルートを定義する意味は何でしょうかfsid=0
。
- そうすると、共有の設定方法に関する柔軟性が低下します (つまり、異なるファイルシステム上で
nocrossmount
? を使用しない限り、継承の問題が発生します)。 - 古いスタイルの NFSv3 セットアップを前提とすると、マウントできないので
/etc
、どのような追加のセキュリティが提供されるのでしょうか?
そこにマウントされ、異なる ACL でエクスポートされる個別のファイル システムのマウント領域であるfsid=0
場合にのみ意味がありますか?/exports
NFS サーバーの設定が逆転したように思います。 Solaris の昔は、共有するものはすべて の下に直接マウントされ/export
、 から共有されていました。 サーバーは/home/user
にバインド マウントされていました/export/home/user
。 しかし、現在は が/home
実際のファイルシステムのマウント場所であり、 の下にバインド マウントされています/exports
。
これは正しいです?
ご注意ください: 上記の例は説明のみを目的としているので、 を使用しないことの賢明さについてのコメントはご遠慮くださいno_squash_root
。
どうもありがとう。
答え1
これは、NFS「マウント」プロトコルの動作方法に関するアーキテクチャ上の変更です。
NFSv2/v3 では、完全に独立した「MOUNT」RPC プロトコルがあり、クライアントはパスによってエクスポートされたファイルシステムのファイルハンドルを取得できました。しかし、その後の WebNFS、そしてその後の NFSv4 では、マウントはインバンド NFS 操作に変更され、同時に操作は単一の「ルート」ファイルハンドルを返すように変更され、そこからすべてのパス検索が派生しました。(実際には、WebNFS にはそのようなルートが 2 つあり、もう 1 つは nfs:// URL の「パブリック」ルートでしたが、これは NFSv4 には採用されませんでした。)
したがって、「PUTROOTFH」操作が機能するためには、なれ何らかのルートファイルシステムでは、ステップをスキップすることができないため、すべてのパストラバーサルは [PUTROOTFH、LOOKUP、LOOKUP、...、LOOKUP、OPEN] の一連の複合操作になります。これは Plan9 の 9p と SMBv2/3 を反映しています。
(これらすべては、このスタイルでは、エクスポートされたファイルシステムのパスがルートに対して相対的になることを意味します。たとえば、/exports/home は "foo:/home" としてマウントされます。ない(「foo:/exports/home」のように。)
MOUNT(path)操作が欠如していることも、"crossmnt"が暗黙的に表れる理由です。ないマウントするものが残っている場合は、すべてルートから下へ「LOOKUP」するだけです。
実際には、NFSv4はどちらのスタイルも使用できます。「fsid=0」エクスポートが定義されていない場合、Linuxカーネル(2.6.33以降)/
自動的に仮想ルートを生成します通常のエクスポート場所のマウント以外は何も含まれません。(これには、NFSv3 と NFSv4 間で同一のマウント パスが保持されるという利点もあります。) つまり、元の v3 スタイルの構成を実際に引き続き使用できます。