내 목표는 "팀" 그룹의 구성원인 모든 사용자가 로컬 마운트 지점을 사용하여 동일한 원격 파일 세트를 편집(읽기/쓰기)할 수 있도록 하는 것입니다. ACL을 사용하여 NFS 및 SSHFS를 시도했지만 아직 성공하지 못했습니다. 여기서는 umask를 올바르게 설정하여 SSHFS가 작동하도록 하려고 합니다(이론적으로 이것이 내가 겪고 있는 문제를 해결해야 합니다).
업데이트된 문제 설명:
user1, user2 및 user3은 모두 동일한 클라이언트 컴퓨터에 로그인되어 있습니다. 모든 사람은 "팀" 그룹의 구성원입니다. 클라이언트 컴퓨터는 SSHFS를 통해 공유를 마운트합니다. 클라이언트와 서버는 Arch Linux를 실행합니다(며칠 전에 업데이트됨). 클라이언트는 KDE 데스크탑을 실행합니다. SSHFS 마운트는 user3@sshfsrv 및 옵션allow_other를 사용하여 수행됩니다.
서버에서 공유 디렉터리에는 user3(소유자) rwx 및 그룹(팀) rwx 권한이 있고 다른 디렉터리에는 rx 권한이 있습니다. gid 고정 비트는 를 통해 설정됩니다 chmod g+s
. umask 중심 구성에 대한 모든 ACL을 제거했습니다.
첫 번째 질문:
user2는 XSane(Gnome 애플리케이션)을 사용하여 문서를 스캔하고 SSHFS 마운트 지점의 일부인 Shared1 디렉터리에 저장하려고 시도합니다. 권한 문제로 인해 저장 작업이 실패했습니다. 0바이트 파일을 씁니다. 이 파일의 권한은 소유자(user3) rw 및 그룹(팀) 읽기 전용(다른 권한 없음)입니다. 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(/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
마스터 PID: 4853(sshd)이 표시됩니다. 기본 프로세스 상태는 umask가 022로 표시됩니다. 그러나 올바른 umask 006을 보여주는 sftp 하위 시스템에 대한 프로세스 정보를 아래에 제공하겠습니다.
# 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
원래 질문 - 위 업데이트 후에는 건너뛸 수 있습니다.
SSHFS 파일 서버의 Shared1 디렉터리를 다양한 클라이언트 컴퓨터에 공유하고 있습니다. 모든 머신은 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 bit()는 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
그러나 나에게 문제는 "Team" 그룹의 사용자가 동일한 프로필에 ForceCommand를 정의했다는 것입니다. 이러한 사용자의 경우 ForceCommand는 위에 나열된 사양 이상을 제공합니다.
해결책은 ForceCommand에 동일한 "-u" 플래그를 추가하는 것입니다.
Match Group team
ForceCommand internal-sftp -u 0002
그런 다음 다음을 실행하십시오.
systemctl restart sshd.service
sshfs 마운트 옵션 umask를 사용하는 것은 권장되지 않습니다. 내가 원하는 동작이 나오지 않습니다.
인용하다:
sshfs의 umask 옵션은 기본 멜트다운 레이어 깊숙이 들어가 잘못 처리됩니다. 내 조언은 그것을 피하는 것입니다. – Ralph Rehnquist 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
사용되지 않습니다 . 설정할 수 있습니다마스크모듈이 있는 모든 사용자 세션(셸 포함)의 경우 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를 별도로 지정해야 합니다. 즉..
Match Group sftp_users
ChrootDirectory /var/www/
ForceCommand internal-sftp -u 0027
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication yes
이는 경쟁 그룹과 완전히 독립적입니다. 답변을 찾는 데 열중하기 때문에 이것을 추가하는 것입니다.