A permissão de compartilhamento do Samba negou o arquivo de gravação do usuário, mas ainda mostra

Question

Problema muito estranho ...

Compartilhar Samba no controle remoto:

[javaerpm]
    path = /u/abas/erpm/java
    force user = erpm
    guest ok = yes
    read only = no
    writeable = yes

Comando Mount no local usando root:

root@crunchbang:/mnt/abas# mount -t cifs -o username=guest,rw,exec,auto //10.0.0.2/javaerpm ./javaerpm

Root pode ler / gravar / cd sem problemas:

root@crunchbang:/mnt/abas# cd javaerpm
root@crunchbang:/mnt/abas/javaerpm# touch test
root@crunchbang:/mnt/abas/javaerpm# ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test
root@crunchbang:/mnt/abas/javaerpm# rm test

Mas se eu alternar para um usuário comum e fizer a mesma coisa, recebo isso:

shawn@crunchbang:/mnt/abas/javaerpm$ touch test
touch: cannot touch 'test': Permission denied

Eu posso ll e posso ver que ele escreveu o arquivo de qualquer maneira:

shawn@crunchbang:/mnt/abas/javaerpm$ ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test

Eu posso até rm sem problemas:

shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$

Eu tentei diferentes opções de montagem. uid=501 não muda nada. Tentei nounix mas depois não funciona nada e não vejo nada usando usuário root ou shawn.

    

Answer 1

_{Nota: Estou apenas supondo aqui, não sou um guru de samba.}

O Samba / CIFS, pelo menos do jeito que você está usando aqui, não reproduz credenciais entre o servidor e o cliente. Por causa da diretiva force user no servidor, todas as operações são executadas como o usuário erpm no servidor. No entanto, como o cliente e o servidor estão executando um sistema unix, eles negociaram automaticamente as extensões CIFS POSIX . Isso faz com que as permissões do UNIX pareçam funcionar até certo ponto, mas apenas na medida em que o servidor permitir, e você se deparou com um caso em que o que as permissões do Unix reivindicam e o que o servidor permite diferem.

Você notará que todos os arquivos aparecem como o ID do usuário 501. Esse é o uid deles no servidor.

Quando você tenta criar ou remover um arquivo, isso requer permissão de gravação no diretório. Todos os acessos são mapeados para um único usuário no servidor, portanto, a permissão de gravação resume se erpm tem permissão para gravar nesse diretório no servidor. A resposta é sim.

Quando você executa touch , ele cria o arquivo e altera seu horário de modificação. Alterar o tempo de modificação de um arquivo requer propriedade, e isso é testado pelo código genérico do sistema de arquivos, no lado do cliente.

Se você executar strace touch test , notará que open call (que cria o arquivo) é bem-sucedido e, em seguida, utimes chama (ou melhor, no Linux o sistema utimensat chamada) falha em definir os horários.

Isto é realmente um pouco estranho porque utimes deve ter sucesso, já que touch o chama com um argumento NULL (significando “set the timestamp to the time atual”), e isso é suposto ser permitido a qualquer chamador que possa escrever no arquivo, e não apenas ao proprietário, como configurar um timestamp arbitrário. Eu suspeito que utimensat está realmente fazendo uma verificação baseada em permissões e determinando que as permissões digam que você não pode gravar nesse arquivo, mesmo que o sistema de arquivos permita uma operação de gravação, independentemente das permissões reais.

A principal vantagem das extensões POSI do CIFS, quando o lado do servidor está sendo executado com as permissões de um usuário não raiz, é transportar o bit executável e, possivelmente, a propriedade do grupo. Pode ser menos confuso se você mapear a propriedade do usuário para um único usuário do lado do cliente com a opção forceuid mount.