FTP SMNT 如何分开身份与命名空间

摘要

设想一条已经完成认证的 FTP 控制连接。服务器知道用户是谁，也已接受必要的账户信息；客户端和服务器还约定了表示类型、传输模式等参数。随后，客户端发出 SMNT，要求换上一套文件系统结构。

RFC 959 对这个动作的描述很短，却明确列出了保留项：用户的登录信息、记账信息和传输参数都不改变。命令参数是一条路径，用来标识某个目录，或由具体系统定义的一组文件。

所以，SMNT 不是重新登录的缩写，也不是把控制连接恢复到初始状态。它是在现有会话内部改变名字解析所依赖的结构。协议由此承认：认证主体与资源命名空间是两种可以独立变化的状态。

RFC 959 里还有两个适合比较的命令。CWD 更改工作目录或数据集，但同样保留登录和记账信息。它改变的是当前结构内的位置。REIN 则清除用户、账户和传输参数，让连接回到接近刚建立时的状态。

三者构成一张清楚的状态图。CWD 改位置；SMNT 改赋予位置含义的结构；REIN 改会话上下文本身。若把它们统称为“目录导航”，就会漏掉各自需要废止的安全假设。

这种区分也解释了标题中的“幸存”。登录之所以能跨过 SMNT，正是因为规范把挂载结构视为身份之外的状态。保留并不是无事发生，而是明确决定哪些状态不随这次切换失效。

FTP 从未规定所有系统必须使用统一的路径语法。RFC 959 把具体形式留给两端涉及的文件系统。RFC 3659 在扩展 FTP 时仍提醒客户端：除 TVFS 模型外，路径语法依赖服务器，最好把服务器返回的路径原样保存并原样重发。

这条规则可以避免客户端擅自改写字符，却无法冻结命名空间。假设挂载前后都出现 /reports/current，其字节可以完全相同，背后的根目录、存储介质、访问策略和对象却可能已经不同。

因此，可靠的资源证据不能只有路径。至少还要包含服务器端点、认证主体、适用时的虚拟主机、当前挂载结构、工作目录、路径的原始表示以及时间。只记录“某用户访问某路径”，看上去简洁，实际上把决定对象身份的关键状态丢掉了。

这里也必须守住证据边界。规范把文件组定义为依赖系统，并未证明所有服务器使用相同的挂载机制。可以确定的是：FTP 给“更换解析上下文、保留若干会话状态”分配了一个标准请求。

RFC 5797 整理 FTP 命令登记时，把 SMNT 列为访问控制类命令，要求级别是可选，并归入基础 FTP 集合。IANA 当前登记表延续了这些属性。

这个分类提醒我们，挂载不是界面偏好。结构一换，可到达的对象集合与同名路径的解析结果都可能改变。服务器仍需判断当前主体是否有权执行切换，并在新结构中重新得出授权结果。登录成功不等于获准挂载所有结构。

RFC 1123 给出了互操作底线：服务器必须支持 CWD，但 SMNT 仍属可选。也就是说，在已提供的命名空间里移动是通用能力；把整个空间换掉不是。

IANA FTP 命令与扩展登记表证明命令名与文档语义受到协调，却不证明某台服务器已经部署、某个用户有权限或某次挂载成功。即使会话记录里有成功回复，它也只能证明一次状态转换被接受，不能自动证明转换前后的同名路径是同一对象。

较晚出现的虚拟主机选择采用了相反顺序。RFC 7151 定义 HOST，让客户端在共享服务器上选定虚拟主机。它要求命令发生在认证前；认证后再发，服务器应回复 503。

原因在于，虚拟主机可能决定可用的认证方法以及哪些用户被授权。此时，主机不是身份之外的资源容器，而是定义身份有效域的一部分。如果先登录再换主机，原来的主体就可能被带进一个不承认它的域。

HOST 并没有取代 SMNT，两者也不是同一种功能。但对比很有价值：若上下文只改变身份之下的资源空间，系统可以选择保留身份，并针对新空间重新授权；若上下文决定什么身份能够存在或被接受，它就应当在认证前确定。

真正的问题从来不是“这看起来像不像导航”，而是“这次切换会使哪些安全事实失效”。

今天很少有人在 FTP 会话中交互式切换文件系统结构，SMNT 因此显得像协议化石。它表达的问题却越来越常见：云控制台保留用户登录而切换项目，企业后台保留操作者而切换租户，容器进程不变而挂载视图改变。

这些系统不是 FTP 的直接翻版。可继承的是设计纪律：把身份、命名空间、授权缓存与资源标识分开建模；明确哪些状态在切换后保留；让日志记录真正决定名字含义的上下文。

主体不是命名空间。路径脱离解析环境就不是对象标识。连接不断也不能证明存储平面没变。SMNT 让登录跨过了文件系统切换，也因此告诉后人：最需要记录的恰恰是那次没有终止登录的变化。