☰

服务器：

tag-icon • tag-icon permissions acl sshfs
服务器：

我想允许同一组（“团队”）中的用户编辑服务器上的相同文件。包含这些文件的目录是通过 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，并且文件不具有组的读写权限，从而阻止该组中的用户处理相同的文件。

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

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

为什么客户端上没有默认 ACL？

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

更新1：

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

在服务器上，systemctl status sshd显示主 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：

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

该声明需要更多细节

请参阅下面的详细信息。

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 设置虽然在我的命令行测试中工作正常，但对桌面用户不起作用。我们发现文件管理器无法移动文件并崩溃，并且多个用户应用程序尝试使用错误的权限保存文件和/或根本无法保存文件。那是一场灾难。

相关内容