如何在 SSHFS 中使用 ACL

Question

我想允许同一组（“团队”）中的用户在服务器上编辑相同的文件。包含这些文件的目录是通过 SSHFS 挂载的。

到目前为止，我无法使用 umask 设置*来实现我的目标。现在我将尝试 ACL。我在服务器上的目录中设置了以下默认 ACL，然后将其安装在客户端上。

服务器：

setfacl -d -m g::rwx .
[root@sshfsrv]# getfacl .
# file: .
# owner: user3
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

客户：

该目录安装在客户端上sshfs -o allow_other,default_permissions（并且启用了 allow_other 选项）。

客户端上不存在默认 ACL，并且文件没有组的 rw 权限，从而阻止该组中的用户处理相同的文件。

[user3@client2]# getfacl .
# file: .
# owner: user3
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

我已重新启动 sshd，并且已注销并重新登录客户端。尝试setfacl在客户端上运行命令失败，并显示“不支持操作”。

为什么客户端上不存在默认 ACL？

是否有另一种方法可以实现我的目标，即允许属于“团队”组成员并在客户端 PC 上登录的所有用户使用本地安装在（r/w）同一组远程文件上进行协作观点。

更新1：

客户端和服务器都运行 OpenSSH_7.5p1，2017 年 5 月 25 日的 OpenSSL 1.1.0f。都运行 Arch Linux。

在服务器上，systemctl status sshd显示 Main PID: 4853 (sshd)

# cat /proc/4853/status
Name:   sshd
Umask:  0022
State:  S (sleeping)
Tgid:   4853
Ngid:   0
Pid:    4853
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups:  
NStgid: 4853
NSpid:  4853
NSpgid: 4853
NSsid:  4853
VmPeak:    47028 kB
VmSize:    47028 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      5644 kB
VmRSS:      5644 kB
RssAnon:             692 kB
RssFile:            4952 kB
RssShmem:              0 kB
VmData:      752 kB
VmStk:       132 kB
VmExe:       744 kB
VmLib:      6260 kB
VmPTE:       120 kB
VmPMD:        16 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
Threads:        1
SigQ:   0/62965
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180014005
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp:        0
Cpus_allowed:   3f
Cpus_allowed_list:      0-5
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        25
nonvoluntary_ctxt_switches:     2

在 /etc/ssh/sshd_config 我们有这个 Match 子句：

Match Group team
  ForceCommand internal-sftp -u 0006

我可以根据要求提供更多信息。

更新2：

我想允许“团队”组中的用户编辑（rw）远程服务器上的相同文件（通过本地安装）。

该声明需要更多细节

请参阅下面的详细信息。

SSHFS挂载什么用户？

该组team包含 3 个用户：user1、user2、user3。他们中的任何一个都可以进行 SSHFS 挂载。但问题总是成为其他两个用户的权限/访问。所以我的问题真的涉及组中的其他用户，而不是在 mount 命令中命名的用户。我已经尝试过 mount 命令的变体，但它目前看起来像这样：

user3@sshfsrv:/home/common /home/common fuse.sshfs x-systemd.automount,_netdev,user,follow_symlinks,identityfile=/home/user3/.ssh/id_rsa,allow_other,default_permissions               0 0

本地用户是否映射到远程服务器上同一组中的用户？

用户和组具有相同的 ID。不需要映射。

SSHFS 通常是一个坏主意（受 TCP 崩溃的影响），尤其是当多个用户使用它时。

我以前没有听说过这个。许多聪明人推荐SSHFS。但如果我们不能让它发挥作用，我们将别无选择，只能转向别的东西......

你有没有考虑过像 NFS over IPSec 这样的东西？

我们使用 NFS 十年，在权限方面从来都不是很令人满意。一些“专家”建议我们切换到 SSHFS，我们刚刚这样做了。他说这将解决我们的权限问题。到目前为止，转换进展并不顺利，正如您从问题中看到的那样，但我希望凭借一些知识我们将解决这些问题。还没有准备好放弃 SSHFS，但我们总是有可能不得不回到 NFS，尽管它在管理用户权限/访问方面确实不是很令人满意。

或者也许只是使用 Git 而不是允许人们直接编辑文件。

Git 不是这种情况的解决方案。

脚注：

* umask 设置虽然在我的命令行测试中运行良好，但对桌面用户不起作用。我们发现文件管理器无法移动文件并崩溃，并且一些用户应用程序试图以错误的权限保存文件和/或根本无法保存文件。那是一场灾难。