Como usar o ACL com o SSHFS

Question

Eu quero permitir que os usuários do mesmo grupo ("equipe") editem os mesmos arquivos no servidor. O diretório que contém esses arquivos é montado via SSHFS.

Até agora, não consegui atingir meu objetivo usando a configuração de umask *. Agora vou tentar o ACL. Eu defino as seguintes ACLs padrão no diretório do servidor, depois montei no cliente.

Servidor:

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

Cliente:

O diretório é montado no cliente com sshfs -o allow_other,default_permissions (e a opção allow_other está habilitada).

As ACLs padrão não estão presentes no cliente e os arquivos não têm permissões de rw para o grupo, impedindo que os usuários deste grupo trabalhem nos mesmos arquivos.

[user3@client2]# getfacl .
# file: .
# owner: user3
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

Eu reiniciei o sshd e fiz o logout e retornei ao cliente. Tentar executar o comando setfacl no cliente falha com "Operação não suportada".

Por que a ACL padrão não está presente no cliente?

Existe outro método pelo qual eu posso alcançar meu objetivo de permitir que todos os usuários que sejam membros do grupo "equipe" e que façam logon no computador cliente colaborem (r / w) com o mesmo conjunto de arquivos remotos usando um ponto de montagem local.

Update1:

O cliente e o servidor estão executando o OpenSSH_7.5p1, o OpenSSL 1.1.0f, de 25 de maio de 2017. Ambos executam o Arch Linux.

No servidor, systemctl status sshd mostra o PID principal: 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

Em / etc / ssh / sshd_config, temos esta cláusula Match:

Match Group team
  ForceCommand internal-sftp -u 0006

Eu posso fornecer mais informações a pedido.

Update2:

I want to allow users in the "team" group to edit (rw) the same files on the remote server (via local mounts).

essa declaração precisa de muito mais detalhes

Veja os detalhes abaixo.

Qual usuário o SSHFS monta?

O grupo team contém 3 usuários: usuário1, usuário2, usuário3. Qualquer um deles pode fazer a montagem SSHFS. Mas o problema sempre se torna permissões / acesso para os outros dois usuários. Então, minha pergunta realmente diz respeito aos outros usuários do grupo que não são o nome do comando mount. Eu tentei variações no comando mount, mas atualmente é assim:

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

Os usuários locais são mapeados para usuários no mesmo grupo no servidor remoto?

Os usuários e grupos têm os mesmos IDs. Nenhum mapeamento é necessário.

O SSHFS é uma má ideia em geral (sujeito a fusão TCP) e particularmente quando vários usuários o estão usando.

Eu não ouvi isso antes. Muitas pessoas inteligentes recomendam o SSHFS. Mas se não conseguirmos dar certo, não teremos outra escolha senão mudar para outra coisa ...

Você considerou algo como o NFS sobre IPSec?

Nós usamos o NFS por dez anos e nunca foi muito satisfatório em termos de permissões. Algum "especialista" recomendou que mudássemos para o SSHFS, o que acabamos de fazer. Ele disse que resolveria nossos problemas de permissões. Até agora, a mudança não está indo bem, como você vê a partir da pergunta, mas estou esperançoso de que com algum conhecimento, vamos resolver esses problemas. Ainda não está pronto para desistir do SSHFS, mas é sempre possível que tenhamos que voltar ao NFS, embora realmente não tenha sido muito satisfatório em termos de gerenciamento de permissões de usuário / acesso.

Ou talvez apenas use o Git em vez de permitir que as pessoas editem arquivos diretamente.

O Git não é uma solução para esta situação.

Notas de rodapé:

* as configurações de umask, enquanto funcionava bem no meu teste de linha de comando, não funcionava para usuários de desktop. Descobrimos que o gerenciador de arquivos não conseguiu mover arquivos e travar e vários aplicativos de usuário tentavam salvar arquivos com as permissões erradas e / ou não conseguir salvar arquivos. Foi um desastre.