要約

  • RFC 2054はTCP 2049、UDP 2049、NFSv3の公共ゼロ長ハンドルを順に試し、特定の失敗に応じてv2、PORTMAP、従来のMOUNTへ戻るクライアント手順を示した。
  • 公共ハンドルは最初の参照を得るための予約値であり、本人確認、exportの許可、完全な経路検証、READ成功を保証しない。
  • 多要素LOOKUPは往復を減らす一方、標準pathとserver固有path、symbolic link、別filesystemへの横断をそれぞれ別条件として残した。

従来の開始点は二段階で見つかった

通常のNFSクライアントは、目的のpathだけで操作を始められなかった。まずport 111のbinding serviceにRPC programの所在を尋ね、固定portを持たないMOUNT serviceを見つける。次にMOUNTPROC_MNTでexport pathをserver生成の初期filehandleへ変換し、そこからNFS操作に入る。

この分業は、program discovery、export選択、file operationを別の責任に保つ。しかし広域網では往復が待ち時間となり、動的なMOUNT portはpacket filterやproxyの通過を難しくした。RFC 2054は、一般的な実装慣行を仮説として先に試し、外れたときだけ従来手順へ戻る方法を選んだ。

最初の順序は明快である。TCPでserverのport 2049へ接続する。拒否されたらUDP 2049を使う。両方で応答がない場合に限り、PORTMAPでNFS portを調べる。2049は不変の真理ではなく、失敗時の出口を備えた運用上の近道だった。

同じ失敗ではなく、別々の仮説の失敗

serverへ到達すると、clientはWebNFSとNFSv3を仮定し、通常はv3公共ハンドルを使ってpathのLOOKUPを送る。RPCのPROG_MISMATCHはprogram versionが違うという狭い証拠であり、v2公共ハンドルでの再試行を導く。

一方、NFS3ERR_STALE、NFS3ERR_INVAL、NFS3ERR_BADHANDLEは、serverが公共ハンドルを認識しないことを示す。この場合はversionを変えるだけでは足りない。PORTMAPでMOUNT serviceを探し、該当するMOUNT版から初期ハンドルを得る必要がある。TCP拒否、UDP無応答、version不一致、予約ハンドル拒否を一つの「障害」にまとめれば、正しい後退位置を失う。

zeroは待ち合わせ場所であって資格証明ではない

通常のNFS filehandleはserverが作るopaqueな値である。公共ハンドルだけが予約された例外で、v2では32個のzero octet、v3では長さzeroのhandleとなる。その値はinode、user、export名、秘密鍵、権限を表さない。server管理者が結び付けた場所から解釈を始める合図にすぎない。

対になるRFC 2055は、この境界をさらに明確にする。未exportの宛先にはhandleを返せない。別のexport済みfilesystemへpathが渡る場合でも、MOUNT時だけaccessを調べるserverは自動的に許可できず、errorを返さなければならない。各NFS requestでexport accessを確認するserverには余地があるが、権限の根拠はその確認であり、公共ハンドルではない。

一回のLOOKUPに残された複数の判断

通常のLOOKUPはdirectory handleに対して一つのmember名を解く。a/b/cなら三回必要になる。公共ハンドルに対するmulti-component LOOKUPは全体を一度に渡し、最終componentのhandleを返せる。

通信回数が減っても文法は消えない。ASCIIで始まるcanonical pathはslash区切りで、component内のslash、percent、非ASCII octetをescapeする。先頭slashならserver rootから、そうでなければ公共ハンドルに結び付いたdirectoryから評価する。先頭octet 0x80はserver native pathを選ぶ。二つは同じ名前の表記揺れではなく、異なる解釈規則である。

途中のsymbolic linkはserverが解くが、最後のcomponentがlinkなら、そのlinkのhandleを返しclientがREADLINKする。絶対targetは公共ハンドルから再評価し、相対targetはlinkを指した最後のcomponentへ置き換えて再度LOOKUPする。RFC 2054がこのclient処理を定めるのは、canonical multi-component lookupで得たlinkに限られる。

filesystem横断にも条件がある。通常のNFS LOOKUPはserver mountpointを越えない。公共ハンドルから越えられるのは、移動先がexportされ、serverがRFC 2055のspanning semanticsを実装する場合だけだ。成功したLOOKUPが証明するのは、その時点の名前空間とpolicyで、その一回の解析がhandleを返したことまでである。

成功を三つのreceiptに分ける

portの応答、公共ハンドルの認識、LOOKUPの成功は別々のreceiptである。最初はprogram surfaceが答えたこと、次は予約された出発点が受理されたこと、最後は命名操作がhandleを作ったことを示す。どれも、残りの段階を自動的に証明しない。

file accessを主張するには、相手のidentity、必要なauthenticationとintegrity、exportとoperationのauthorization、linkと横断の結果、期待したcontent、READ完了、さらに必要ならstable storageやapplication outcomeを別に確かめる必要がある。RFC 2054はNFS/RPCのsecurity considerationsを引き継ぎ、secure connectionを別途交渉できるとしただけで、zero handleにsecurity authorityを与えていない。

出典