要約

  • RFC 959のSMNTは、ログイン、課金情報、転送パラメーターを変えずに別のファイルシステム構造をマウントする任意コマンドだった。
  • したがって、切替前後で同じ文字列のパスが現れても、同じオブジェクトや同じ権限を示すとは限らない。
  • 後年のHOSTは仮想ホストが認証方法や利用者集合を決め得るため認証前に限られた。この対照は、文脈変更を越えて主体を維持できる条件を示す。

変わらないものを列挙した仕様

RFC 959におけるStructure Mountの記述は短い。利用者は、ディレクトリまたはシステム依存のファイル群を示すパスを引数にして、別のファイルシステムデータ構造をマウントできる。そして仕様は、変更しないものをわざわざ挙げる。ログイン情報、課金情報、転送パラメーターである。

ここに設計の核心がある。SMNTは接続の作り直しでも、認証のやり直しでもない。確立済みの制御セッションの内側で、名前解決の土台だけを動かす。その結果、同じ主体が同じ転送条件を持ったまま、別の資源空間に立てる。

「セッションが同じ」という観測は正しい。しかし、そこから「対象も同じ」と進む推論は正しくない。仕様自身が、その二つの状態を独立に扱っていた。

CWDより深く、REINより浅い

同じRFCのCWDは、ログインや課金情報を変えずに作業ディレクトリまたはデータセットを移す。現在の構造の中で位置を変える操作である。一方、REINは利用者、アカウント、転送パラメーターを消去し、制御接続を新規接続に近い状態へ戻す。

SMNTはその中間にある。位置だけではなく位置を構成する構造を替えるが、主体までは捨てない。三つを同じ「移動」機能として扱えば、どの前提が失効するのか見えなくなる。

状態遷移として読めば明瞭だ。CWD後は相対基点を確認する。SMNT後は名前空間と認可を確認する。REIN後は認証と転送条件から確認し直す。コマンド名の古さより、この粒度の方が現代的である。

正確なパスにも文脈が要る

RFC 959は、パス名に普遍的な標準形式を設けなかった。表現は関係するファイルシステムに従う。RFC 3659も、TVFSの外では構文がサーバー依存であるため、受け取ったパスを正確に保持し、そのまま返すようクライアントに勧めている。

しかし、文字列を完全に保持することと、対象を完全に同定することは別である。/pub/latestという同じバイト列でも、SMNTの前後では別のルート、別の媒体、別のポリシーを通って解決され得る。

監査証拠には、パスだけでなく、サーバー終端、認証主体、必要なら選択済み仮想ホスト、マウント構造、作業ディレクトリ、パス表現、時刻が必要になる。主体とパスだけのログは読みやすいが、対象を決めた状態を欠いている。

なお、仕様はすべての実装が同じマウント機構を使ったとは述べていない。対象となるファイル群はシステム依存である。確実に言えるのは、FTPが「他のセッション状態を保ちながら構造を替える」という要求を標準語彙にしたことまでだ。

任意機能でもアクセス制御である

RFC 5797はFTPコマンド登録簿を整理し、SMNTをアクセス制御クラス、任意、baseとして分類した。現在のIANA表もこの意味を保持している。

アクセス制御という分類は重要だ。マウント先が変われば、到達可能な資源や同名パスの認可結果が変わり得る。認証済みであることは、どの構造でも選べる許可を意味しない。サーバーは切替自体を許可するか判断し、その後の操作を新しい名前空間で評価しなければならない。

RFC 1123ではCWDが必須、SMNTは任意である。既存の空間を移動する能力は相互運用の基礎だったが、空間そのものを交換する能力は基礎ではなかった。

IANAのFTP Commands and Extensionsは、名称と文書上の意味が調整されている証拠である。現役サーバーの実装、利用者の権限、特定セッションでの成功を示すものではない。肯定応答があっても、それは遷移の受理を示すだけで、切替前後の同名パスが同一物だったことまでは示さない。

HOSTがログイン後を拒む理由

RFC 7151のHOSTは、共有FTPサーバー上で仮想ホストを選ぶための後発コマンドである。これは認証より前に送らなければならず、認証後なら503となる。

仮想ホストによって、利用可能な認証方式や許可された利用者集合が異なり得るからだ。ホストは単なる資源の入れ物ではなく、主体を認める権威領域の一部になる。既に認証した主体を別ホストへそのまま運べば、認証の根拠が消える可能性がある。

HOSTはSMNTの後継でも代替でもない。だが順序の違いは有益である。資源空間だけが変わり、主体の根拠が独立しているなら、主体を維持して新空間で認可を再評価できる場合がある。変更する文脈が有効な主体そのものを決めるなら、その文脈は認証前に選ばなければならない。

化石ではなく、監査設計の小さな教材

現代のFTP利用でSMNTを目にする機会は少ない。それでも同じ問題は、クラウドのプロジェクト切替、企業管理画面のテナント切替、コンテナのマウント名前空間に現れる。人のログインやプロセスは続き、資源の見え方だけが変わる。

これらをFTPと同一視する必要はない。受け継ぐべきなのは、継続する状態と失効する状態を明示し、資源名を解決した文脈を証拠に含める姿勢である。

認証主体は名前空間ではない。パスは文脈なしのオブジェクト識別子ではない。接続の連続性は、資源平面の連続性を保証しない。ログインが切替を越えて残ったからこそ、切替は独立した監査事実になった。

出典