关于SSHFS的default_permissions、ACLs支持及FUSE挂载选项的技术咨询

让我一步步帮你拆解这些关于SSHFS权限和ACLs的疑问：

1. 为什么SSHFS挂载选项default_permissions不支持ACLs？ #

要搞懂这个问题，得先明确default_permissions的核心作用：它把文件系统的权限检查工作从用户空间的SSHFS进程转移到了Linux内核手中。

内核处理权限时，只会依赖本地挂载点的基础文件权限位（rwx）和用户/组ID（U/GID）做判断——它完全不知道这是一个远程挂载的文件系统，也没法和SSHFS进程通信去获取远程主机上的ACL规则。当开启default_permissions后，内核不会主动询问SSHFS任何关于ACLs的信息，自然也就无法应用远程的ACL策略，这就导致了该选项和ACLs支持互斥。

2. 关于FUSE GitHub页面的几个疑问 #

2.1 相关表述是否意味着不使用default_permissions时SSHFS支持ACLs？ #

没错，就是这个意思。当你不指定default_permissions时，权限检查的逻辑回到了SSHFS用户空间进程手里。SSHFS会直接和远程主机通信，获取目标文件/目录的完整ACL配置，然后在本地处理访问请求时严格应用这些规则——相当于把远程的ACL策略完整同步到了本地挂载的访问控制中。

2.2 是否意味着若需ACLs支持及恰当安全性，default_permissions与allow_other均不应作为挂载选项？（显然，无default_permissions时不应使用allow_other。） #

这个判断完全准确，理由有两点：

• 首先，default_permissions直接阻断了ACLs支持，所以要启用ACLs必须关闭这个选项；
• 其次，allow_other允许非挂载用户访问挂载点，但当没有default_permissions时，内核不会做任何权限兜底检查，所有访问控制全靠SSHFS进程处理。这种情况下，如果SSHFS的ACL处理存在疏漏（比如版本bug、配置偏差），或者远程主机的ACL策略本身有问题，就会带来不必要的安全风险。官方也明确不推荐在无default_permissions的场景下使用allow_other，因为它会弱化权限控制的可靠性。

所以从ACLs支持和安全性的双重角度，这两个选项都应该避免使用。

2.3 若上述第二个疑问成立，是否意味着未使用default_permissions和allow_other的SSHFS挂载可正确传递远程的访问控制信息？ #

是的，这种情况下，SSHFS会全程接管权限检查逻辑：它会实时同步远程主机的文件权限位、用户组信息以及完整的ACL规则，确保本地用户对挂载文件的访问权限和直接在远程主机上操作的权限完全一致。简单来说，远程的所有访问控制策略都会被正确传递并应用到本地挂载点上。

内容的提问来源于stack exchange，提问作者MountainX