![更新了问题描述:](https://linux22.com/image/118374/%E6%9B%B4%E6%96%B0%E4%BA%86%E9%97%AE%E9%A2%98%E6%8F%8F%E8%BF%B0%EF%BC%9A.png)
我的目标是允许属于“团队”组成员的所有用户使用本地安装点编辑(读/写)同一组远程文件——正常工作协作。我尝试过使用 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
- https://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
- https://unix.stackexchange.com/a/289278/15010
编辑:
虽然此解决方案适用于命令行和某些桌面应用程序(例如,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
这对于比赛组来说是完全独立的。之所以添加这个,是因为它让我疯狂地寻找答案。