동일한 그룹("팀")의 사용자가 서버에서 동일한 파일을 편집할 수 있도록 허용하고 싶습니다. 이러한 파일이 포함된 디렉터리는 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이 디렉토리는 클라이언트에 설치되며, 허용되는 옵션은 허용됩니다.

클라이언트에 기본 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일에 릴리스된 OpenSSL 1.1.0f인 OpenSSH_7.5p1을 실행하고 있습니다. 둘 다 아치 리눅스를 실행합니다.

서버에는 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에는 user1, user2, user3이라는 3명의 사용자가 포함되어 있습니다. 둘 중 하나를 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를 추천합니다. 하지만 제대로 작동하지 않으면 다른 방법으로 전환하는 것 외에는 선택의 여지가 없습니다…

IPSec를 통한 NFS와 같은 것을 고려해 보셨나요?

우리는 10년 동안 NFS를 사용해 왔지만 권한 측면에서 결코 만족스러운 적이 없습니다. 일부 "전문가"는 SSHFS로 전환할 것을 제안했고 우리는 방금 그렇게 했습니다. 그는 이것이 우리의 허가 문제를 해결할 것이라고 말했습니다. 지금까지는 질문에서 볼 수 있듯이 변환이 잘 진행되지 않지만 어느 정도 지식을 갖고 문제를 해결할 수 있기를 바랍니다. 아직 SSHFS를 포기할 준비가 되지 않았지만 NFS로 돌아가야 할 가능성은 항상 있습니다. 하지만 사용자 권한/액세스 관리 측면에서 확실히 덜 만족스럽습니다.

아니면 사람들이 파일을 직접 편집하도록 허용하는 대신 Git을 사용할 수도 있습니다.

Git은 이 상황에 대한 해결책이 아닙니다.

각주:

* 명령줄 테스트에서는 umask 설정이 제대로 작동했지만 데스크톱 사용자에게는 작동하지 않습니다. 파일 관리자가 파일을 이동할 수 없어 충돌이 발생했으며 여러 사용자 응용 프로그램이 잘못된 권한으로 파일을 저장하려고 시도했거나 파일 저장에 전혀 실패했다는 사실을 발견했습니다. 그것은 재앙이었습니다.