为 SFTP 事务设置 umask 的正确方法？

Question

我的目标是允许作为“团队”组成员的所有用户使用本地安装点编辑（r/w）同一组远程文件——正常的工作协作。我已经尝试过使用 ACL 的 NFS 和 SSHFS，但没有成功。在这里，我试图通过使 umask 正确来让 SSHFS 工作（理论上，这应该可以解决我遇到的问题）。

更新问题描述：

user1、user2 和 user3 都登录到同一台客户端计算机。都是“团队”组的成员。客户端计算机通过 SSHFS 挂载共享。客户端和服务器运行 Arch Linux（几天前更新）。客户端运行 KDE 桌面。SSHFS 挂载是通过 user3@sshfsrv 和选项 allow_other 完成的。

在服务器上，共享目录的权限为user3（所有者）rwx和组（team）rwx，其他的则为rx权限。gid 粘滞位设置为chmod g+s. 我们删除了以 umask 为重点的配置的所有 ACL。

第一个问题：

user2 使用 XSane（一个 Gnome 应用程序）扫描文档并尝试将其保存在 Shared1 目录中，该目录是 SSHFS 挂载点的一部分。由于权限问题，保存操作失败。写入 0 字节文件。该文件的权限是所有者 (user3) rw 和组 (team) 只读（其他无）。user2 可以将扫描的文档保存到他们的主目录。

终端按预期工作：

在终端中，user2可以触摸Shared1目录下的文档，权限为：

-rw-rw---- 1 user3 team 6 Sep 23 19:41 deleteme6.txt

我们获得了正确的 g+rw 权限。请注意，所有权是 user3，而这是创建文件的 user2。在 /etc/fstab 中，挂载指定为：

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

在终端中，使用文本编辑器（KDE 中的 Kate），用户可以按预期协作处理在 Shared1 中创建的文件。“team”组中的任何用户都可以通过 nano 文本编辑器在 Shared1 中创建和保存文件，组中的任何其他用户都可以编辑/更新它。

第二个问题：

作为临时解决方法，我测试了将扫描图像保存到 user2 的主目录，然后使用 Dolphin 文件管理器将它们移动到 Shared1 目录。权限错误阻止了这一点，有时它会导致 Dolphin 崩溃。

我可以通过在终端中移动文本文件来显示相同​​的结果：

[user2@client2 Shared1]$ echo user2 > /home/user2/MoveMe/deleteme7.txt
[user2@client2 Shared1]$ mv /home/user2/MoveMe/deleteme7.txt .
mv: preserving times for './deleteme7.txt': Operation not permitted
mv: preserving permissions for ‘./deleteme7.txt’: Operation not permitted

上述两个错误似乎是理解问题的关键。如果我改变安装规范使用user2@sshfsrv这些错误走开user2，但随后user1和user3体验它们。唯一没有问题的用户是安装规范中使用的用户。（我原以为allow_othermount 选项会阻止这种情况，但事实并非如此。root在 mount 规范中使用似乎也无济于事。）

删除挂载选项会default_permissions消除这些错误，但也会消除所有权限检查。任何组中的任何用户都可以在 Shared1 中读写文件，这不符合我们的要求。

sftp-server umask 设置：

正如下面 sebasth 所说，当使用 sftp-server 时，不使用 /etc/profile 或 ~/.bashrc 中的 umask。我发现 /etc/ssh/sshd_config 中的以下规范是设置 umask 的一个很好的解决方案：

Subsystem sftp internal-sftp -u 0006

我不想为 sshfs（在 /etc/fstab 中）使用 umask 挂载选项，因为这不会提供所需的行为。

不幸的是，上面的“-u”标志虽然是必需的，但并没有（还）完全解决我上面描述的问题。

新更新：

我已启用 pam_umask，但仅此而已并不能解决问题。仍然需要上面的“-u”选项，我没有看到 pam_umask 添加任何有助于解决此问题的其他内容。以下是当前使用的配置：

/etc/pam.d/system-login
session    optional   pam_umask.so

/etc/login.defs
UMASK           006

Shared1 目录具有这些权限，如服务器端所示。gid 粘滞位设置为chmod g+s. 我们删除了所有 ACL。此目录中的所有文件都具有 g+rw 权限。

drwxrwsr-x  1 user3   team          7996 Sep 23 18:54 .

# cat /etc/group
team:x:50:user1,user2,user3

客户端和服务器都运行 OpenSSH_7.5p1，OpenSSL 1.1.0f，日期为 2017 年 5 月 25 日。这看起来像是最新版本。

在服务器上，systemctl status sshd显示 Main PID: 4853 (sshd)。主 proc 状态显示 umask 为 022。但是，我将在下面进一步提供 sftp 子系统的进程信息，其中显示了正确的 umask 006。

# 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

我们需要查看这个客户端的 sftp-server 进程。它显示了 006 的预期 umask。我不确定 GID 是否正确。1002 是 user3 组的 GID。该目录指定团队组 (GID 50) rwx。

# ps ax | grep sftp*
5112 ?        Ss     0:00 sshd: user3@internal-sftp


# cat /proc/5112/status
Name:   sshd
Umask:  0006
State:  S (sleeping)
Tgid:   5112
Ngid:   0
Pid:    5112
PPid:   5111
TracerPid:      0
Uid:    1002    1002    1002    1002
Gid:    1002    1002    1002    1002
FDSize: 64
Groups: 47 48 49 50 51 52 1002 
NStgid: 5112
NSpid:  5112
NSpgid: 5112
NSsid:  5112
VmPeak:    85280 kB
VmSize:    85276 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      3640 kB
VmRSS:      3640 kB
RssAnon:             980 kB
RssFile:            2660 kB
RssShmem:              0 kB
VmData:     1008 kB
VmStk:       132 kB
VmExe:       744 kB
VmLib:      7352 kB
VmPTE:       184 kB
VmPMD:        12 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
Threads:        1
SigQ:   0/62965
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180010000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
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:        8
nonvoluntary_ctxt_switches:     0

原始问题-上述更新后可能可以跳过此问题

我正在将 Shared1 目录从 SSHFS 文件服务器共享到各种客户端计算机。所有机器都使用 Arch Linux 和 BTRFS。pwck并且grpck在客户端和服务器上都没有报告错误。

我的目标是允许团队组中的所有用户在 Shared1 目录中拥有 rw 权限。由于未知的原因，我无法实现这个目标。一些组成员遇到权限被拒绝错误（写入时），如下所示。

我在看什么？（我已经在 unix.stackexchange.com 上检查了所有相关问题，但我仍然没有解决这个问题。）

服务器：

[user2@sshfsrv Shared1]$ cat /etc/profile
umask 006

[user2@sshfsrv Syncd]$ whoami
user2

[user2@sshfsrv Syncd]$ groups
team user2

[user2@sshfsrv Syncd]$ cat /etc/fuse.conf 
user_allow_other

[root2@sshfsrv Syncd]# cat /proc/18940/status
Name:   sshd
Umask:  0022

请注意以下 setgid 位 ( chmod g+s) 最初已设置：

[user1@sshfsrv Syncd]$ ls -la
total 0
drwxrws--x 1 user1 limited     170 Aug 29 09:47 .
drwxrwxr-x 1 user1 limited      10 Jul  9 14:10 ..
drwxrwsr-x 1 user2 team       7892 Sep 22 17:21 Shared1

[root@sshfsrv Syncd]# getfacl Shared1/
# file: Shared1/
# owner: user2
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

[user2@sshfsrv Shared1]$ umask -S
u=rwx,g=rx,o=x

[user2@sshfsrv Shared1]$ sudo chmod g+w .

[user2@sshfsrv Shared1]$ umask -S
u=rwx,g=rx,o=x

注意：即使在上述步骤之后，仍然没有组写入权限。

[user2@sshfsrv Shared1]$ touch deleteme2.txt
[user2@sshfsrv Shared1]$ echo deleteme > deleteme2.txt 
[user2@sshfsrv Shared1]$ cat deleteme2.txt 
deleteme
[user2@sshfsrv Shared1]$ ls -la deleteme2.txt 
-rw-r----- 1 user2 team 9 Sep 22 17:55 deleteme2.txt

[user2@sshfsrv Shared1]$ getfacl .
# file: .
# owner: user2
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

[root@sshfsrv Syncd]# chmod g-s Shared1/
[root@sshfsrv Syncd]# ls -la
drwxrwxr-x 1 user2      team         7944 Sep 22 17:54 Shared1

客户

[user2@client2 Shared1]$ cat /etc/fstab
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

[user2@client2 Shared1]$ cat /etc/profile
umask 006

[user2@client2 Shared1]$ cat /etc/fuse.conf 
user_allow_other

[user2@client2 Shared1]$ groups
team user2

[user2@client2 Shared1]$ echo deleteme > deleteme2.txt
bash: deleteme2.txt: Permission denied

[user2@client2 Shared1]$ touch deleteme3.txt
touch: setting times of 'deleteme3.txt': Permission denied

[user2@client2 Shared1]$ ls -la
total 19520
drwxrwsr-x 1 user2 team       7918 Sep 22 17:51 .
drwxrws--x 1 user1 limited     170 Aug 29 09:47 ..
-rw-r----- 1 user3 team          0 Sep 22 17:51 deleteme3.txt

Answer 1

一般的解决方案是在 Arch Linux 上的 /etc/ssh/sshd_config 中添加以下行：

Subsystem sftp internal-sftp -u 0002

然而，对我来说，问题是“团队”组的用户在同一个配置文件中定义了一个 ForceCommand。对于这些用户，ForceCommand 覆盖了上面列出的规范。

解决方案是在 ForceCommand 上添加相同的“-u”标志

Match Group team
   ForceCommand internal-sftp -u 0002 

然后运行：

systemctl restart sshd.service

请务必注意，不建议使用 sshfs 挂载选项 umask。它没有产生我想要的行为。

参考：

sshfs 的 umask 选项归结为错误处理的底层保险丝层。事实上，建议是避免它。– Ralph Rönnquist 2016 年 6 月 17 日 7:56了解 sshfs 和 umask

• https://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
• https://unix.stackexchange.com/a/289278/15010

编辑：

虽然此解决方案适用于命令行和某些桌面应用程序（例如，KDE 的 Kate 文本编辑器），但它不能与许多桌面应用程序（包括 KDE 的 Dolphin 文件管理器、XSane 等）一起正常工作。所以结果证明这不是一个好的整体解决方案。