☰

更新了问题描述：

tag-icon • tag-icon permissions sshfs
更新了问题描述：

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

更新了问题描述：

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

在服务器上，共享目录具有user3（所有者）rwx 和group（团队）rwx 权限，而other 具有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 中创建的正如预期的那样。 “团队”组中的任何用户都可以通过 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_other安装选项会阻止这种情况，但事实并非如此。root在安装规范中使用似乎也没有帮助。）

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

sftp 服务器 umask 设置：

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

Subsystem sftp internal-sftp -u 0006

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

不幸的是，上面的“-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显示主 PID：4853 (sshd)。主进程状态显示 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 服务器进程。它显示了预期的 umask 006。我不确定 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在客户端和服务器上都没有报告错误。

我的目标是让Team组中的所有用户都拥有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

答案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 选项会深入到底层熔断层，在那里它被错误地处理。我的建议是避免它。 – 拉尔夫·伦奎斯特 2016 年 6 月 17 日 7:56了解 sshfs 和 umask

编辑：

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

答案2

什么时候sftp服务器被使用时，掩码中/etc/profile未使用。您可以设置掩码对于带有模块的所有用户会话（包括 shell）pam_umask。附加到/etc/pam.d/system-login：

session    optional   pam_umask.so

并在 中配置您的 umask 值/etc/login.defs。

答案3

为尝试 CHROOTED sftp 的管理员添加此内容，因为我遇到的所有答案均不包含此内容 -

在您的配置中，您必须单独指定它，“ForceCommand inside-sftp -u 0027”或您想要的任何 umask。 IE..

  Match Group sftp_users
   ChrootDirectory /var/www/
   ForceCommand internal-sftp -u 0027
   X11Forwarding no
   AllowTcpForwarding no
   PasswordAuthentication yes

这对于比赛组来说是完全独立的。之所以添加这个，是因为它让我疯狂地寻找答案。

相关内容