Altera automaticamente o usuário remoto com sshfs

1

Eu tenho dois servidores remotos, foo e bar . Em ambos os servidores eu tenho um usuário git (com diferente uid e gid). Ambos os servidores estão executando distribuições Debian. Ambos os servidores possuem a chave pública ssh root de cada um em authorized_keys, portanto, todos os comandos relacionados a ssh já funcionam como um encanto.

As contas

git foram configuradas corretamente - o shell padrão está definido como / usr / bin / git-shell, os repositórios estão trabalhando em foo (barra ainda está desconfigurado no assunto).

Estou tentando criar um "diretório compartilhado" entre foo e bar usando sshfs. Em foo eu tenho um diretório / home / git. O diretório pertence ao usuário git (uid / gid 1000 neste caso). Digamos que eu queira montar esta pasta usando sshfs em bar em / mnt / foo-git.

No caso normal, eu usaria apenas sshfs git @ foo / mnt / foo-git (em bar ) para montar o diretório (ou usar fstab, que por sinal é o que eu pretendo fazer uma vez eu recebo o sistema funcionando). No entanto, o git-shell efetivamente me impede de invocar o sftp-server e usar o sshfs da maneira mais simples.

Após mexer um pouco, decidi usar o usuário root para logar (através do ssh), mudar o usuário efetivo com su -l, e iniciar o sftp-server. Para conseguir isso, criei um script simples (em foo ) / sbin / git-sftp-server:

#!/bin/bash
/bin/su -l git -s /bin/bash -c /usr/lib/openssh/sftp-server

E usou a seguinte opção com sshfs ( bar ):

sshfs root@foo /mnt/foo-git -o sftp_server=/sbin/git-sftp-server

O comando parece funcionar, no entanto, ele realmente não altera as permissões da sessão. Quando eu crio um arquivo na barra , no foo o arquivo aparece com o proprietário root . Isso se torna um problema sério, quando os comandos do git não podem alterar o conteúdo dos repositórios, simplesmente por causa do controle básico de acesso ao arquivo Linux.

Neste momento, vejo duas direções possíveis:

  1. Tente forçar a sessão do sshfs com o usuário git . Isso pode me obrigar a mexer em torno do git-shell, mas pode não ser impossível
  2. Encontre uma maneira de corrigir o suing no user git de uma sessão raiz

De qualquer forma, até agora não consegui encontrar uma boa maneira de resolver o problema, mas conto com o seu conselho.

Editar: OK, depois de ler o comentário de @AlexStragies (e testar algumas outras coisas), minha solução está um pouco funcionando. Se eu montar o sistema de arquivos através de sshfs ou fstab com +/- as seguintes opções:

root@foo:/home/git  /mnt/foo-git    fuse.sshfs  defaults,_netdev,uid=998,gid=998,IdentityFile=/root/.ssh/id_rsa,allow_other,sftp_server=/sbin/git-sftp-server" 0 0

E então su -l no usuário git com um shell "normal" e criar um arquivo, o uid / gid do arquivo está definido corretamente para git @ foo. No entanto , digamos que eu crie um arquivo / home / git / cat com usuário root @ foo e privilégios 644. O usuário git @ foo obviamente não pode modificar o arquivo (permissão negada, no entanto fiquei surpreso que ele possa remover o arquivo, mas eu acho que é possível porque ele tem permissão de gravação para a pasta). Na máquina bar , o arquivo parece pertencer ao usuário git , com permissões 644, embora o proprietário real seja root @ foo. Agora, ambos os usuários git e root no foo podem modificar o arquivo cat (com as alterações refletidas na máquina foo ) embora o arquivo ainda seja de propriedade por root com permissões 644.

Isso parece ser um caso estranho de escalonamento de privilégios ou uma solução alternativa que não funciona realmente. Então, minha pergunta agora é: qual deles? E se este último, então o que posso fazer para respeitar adequadamente as permissões do usuário remoto?

    
por Marandil 27.08.2015 / 19:50

0 respostas