Eu tenho um problema parecido com o que foi postado aqui , que um usuário não pode acessar o conteúdo de um diretório que possui. Uma pesquisa rápida mostra algumas outras questões semelhantes, no entanto, o problema sempre parece ser o bit de execução não sendo definido em um diretório. Talvez eu tenha perdido alguma coisa por ter olhado para este por tanto tempo, mas isso não parece ser problema meu.
Como com as outras perguntas, é provavelmente mais fácil mostrar:
me@docker-host:~$ docker exec -it sp-rsync-1 bash
root@sp-rsync-syn-send:/# su --login sync_user
sync_user@sp-rsync-syn-send:~$ ls -al
total 24
drwxr-xr-x 6 sync_user sync_user 4096 Feb 9 20:24 .
drwxr-xr-x 6 root root 4096 Feb 9 20:24 ..
-rw-r--r-- 1 sync_user sync_user 220 Apr 9 2014 .bash_logout
-rw-r--r-- 1 sync_user sync_user 3637 Apr 9 2014 .bashrc
-rw-r--r-- 1 sync_user sync_user 675 Apr 9 2014 .profile
drwx------ 2 sync_user sync_user 4096 Feb 9 20:24 .ssh
Como você pode ver, o diretório .ssh é de propriedade de sync_user with 0700 permissions. No entanto:
sync_user@sp-rsync-syn-send:~$ ls -al .ssh/
ls: cannot open directory .ssh/: Permission denied
Mas parece que o usuário possui o diretório:
sync_user@sp-rsync-syn-send:~$ chmod 0777 .ssh
sync_user@sp-rsync-syn-send:~$ ls -al
total 28
drwxr-xr-x 7 sync_user sync_user 4096 Feb 9 21:23 .
drwxr-xr-x 7 root root 4096 Feb 9 21:05 ..
-rw------- 1 sync_user sync_user 58 Feb 9 21:05 .bash_history
-rw-r--r-- 1 sync_user sync_user 220 Apr 9 2014 .bash_logout
-rw-r--r-- 1 sync_user sync_user 3637 Apr 9 2014 .bashrc
-rw-r--r-- 1 sync_user sync_user 675 Apr 9 2014 .profile
drwxrwxrwx 2 sync_user sync_user 4096 Feb 9 20:24 .ssh
Não que isso ajude:
sync_user@sp-rsync-syn-send:~$ ls -al .ssh/
ls: cannot open directory .ssh/: Permission denied
Para um pouco mais de informação:
sync_user@sp-rsync-syn-send:~$ ls -ain
total 24
885 drwxr-xr-x 6 1200 1200 4096 Feb 9 20:24 .
852 drwxr-xr-x 6 0 0 4096 Feb 9 20:24 ..
905 -rw-r--r-- 1 1200 1200 220 Apr 9 2014 .bash_logout
890 -rw-r--r-- 1 1200 1200 3637 Apr 9 2014 .bashrc
889 -rw-r--r-- 1 1200 1200 675 Apr 9 2014 .profile
904 drwx------ 2 1200 1200 4096 Feb 9 20:24 .ssh
sync_user@sp-rsync-syn-send:~$ id sync_user
uid=1200(sync_user) gid=1200(sync_user) groups=1200(sync_user)
De volta à raiz e listando as permissões dos diretórios:
root@sp-rsync-syn-send:/# ls -ail /home/sync_user/.ssh/
total 16
904 drwx------ 2 sync_user sync_user 4096 Feb 9 20:24 .
885 drwxr-xr-x 6 sync_user sync_user 4096 Feb 9 21:05 ..
917 -rw------- 1 sync_user sync_user 394 Feb 9 18:51 authorized_keys
916 -rw------- 1 sync_user sync_user 1679 Feb 9 18:51 id_rsa
Além disso, as permissões sobre /home e / são 0755 com raiz como proprietário e grupo.
root@sp-rsync-syn-send:/# ls -al /home
total 12
drwxr-xr-x 7 root root 4096 Feb 9 21:05 .
drwxr-xr-x 88 root root 4096 Feb 9 21:17 ..
Para informações adicionais, o usuário foi criado dentro de um contêiner docker como parte do processo de compilação, portanto, minhas suspeitas são de que isso é algo relacionado a como estou sofrendo com esse usuário (portanto, explicitamente usando su --login , ou que isso poderia ser um problema com o sistema de arquivos AUFS.
Atualizar
Só para provar que estou no lugar certo:
sync_user@sp-rsync-syn-send:~$ pwd
/home/sync_user
Atualização de 19 de fevereiro de 2016
Eu não acredito que isso seja uma solução, já que eu pisei lado a questão original, então eu não vou postar como resposta. Para mim, parei explicitamente de criar o diretório .ssh usando um comentário mkdir e, em vez disso, configurei a criação do .ssh colocando-o em / etc / skel.
Richard aponta nos comentários abaixo que existe um bug do Docker com o sistema de arquivos AUFS que eu acho que é bem a causa deste problema; infelizmente eu não tenho tempo para investigar isso como a causa real ou se há uma solução.
Potencialmente, alguns fatos relevantes para qualquer outra pessoa se deparando com esse problema: Versão do Docker: 1.9.1
Tags permissions docker linux