'Permissão negada' para o CD em um diretório, mesmo que as permissões estejam corretas

11

Isso é tão estranho. Conectado a uma caixa Linux (RHEL) como usuário 'g', fazendo um ls -lah

drwxrwxrwx 6 g    g    4.0K Jun 23 13:27 .
drwxrw-r-x 6 root root 4.0K Jun 23 13:15 ..
-rwxrw---- 1 g    g     678 Jun 23 13:26 .bash_history
-rwxrw---- 1 g    g      33 Jun 23 13:15 .bash_logout
-rwxrw---- 1 g    g     176 Jun 23 13:15 .bash_profile
-rwxrw---- 1 g    g     124 Jun 23 13:15 .bashrc
drw-r----- 2 g    g    4.0K Jun 23 13:25 .ssh

Assim, o usuário 'g' no grupo 'g' / deve / pode ler e gravar no diretório .ssh, mas se eu fizer ls -lah .ssh/ , eu recebo ls: .ssh/: Permission denied . Eu também recebo Permissão negada se eu tentar e cat quaisquer arquivos no diretório

Se eu entrar como root e alterar as permissões para 700 , 744 , 766 ou qualquer coisa, desde que a permissão 'user' seja 7, funciona e posso CD e LS o diretório e os arquivos dentro .

id g retorna

uid=504(g) gid=506(g) groups=506(g)

Editar:

Eu copiei essas permissões exatamente para outra caixa idêntica e não há problema. Eu posso cd em um diretório sem permissões de execução.

    
por Smudge 23.06.2011 / 15:33

5 respostas

26

O diretório irá requerer o bit de execução configurado para que você o insira. Eu não sei o que você testou, mas você não pode entrar em um diretório sem o bit de execução, ou ler arquivos nele:

$ mkdir foo
$ echo "baz" > foo/bar
$ chmod 660 foo
$ cd foo
bash: cd: foo: Permission denied
$ cat foo/bar
cat: foo/bar: Permission denied

Ou seja, a menos que seu processo tenha o conjunto de recursos CAP_DAC_OVERRIDE POSIX (como o root), que permite que você insira diretórios sem o conjunto de bits executáveis, iirc.

Basicamente, você deve tentar manter seu diretório .ssh em 700, e tudo nele em 600, apenas para estar seguro. A página man do ssh fornece instruções por arquivo sobre os proprietários necessários e modos de permissão para arquivos em ~ / .ssh.

    
por 23.06.2011 / 16:22
14

Um diretório requer permissão de execução para cd . Esse é o comportamento esperado.

    
por 23.06.2011 / 15:37
2

Para ls ou cd em um diretório, você precisa de permissões de execução. Enquanto você não os tem, você não pode realmente inspecionar o conteúdo e ver as permissões dos arquivos dentro, então provavelmente as permissões de arquivos estão erradas, se você não conseguir catá-las.

A permissão de diretório 700 e as permissões de arquivo 644 são perfeitamente configuráveis para mim.

    
por 23.06.2011 / 15:43
0

Eu entendo que isso é um problema de arquivo ssh agora? não é um problema chmod geral?

Se sim, tente

$chmod go-w ~/
$chmod 700 ~/.ssh
$chmod 600 ~/.ssh/*
$chmod 600 ~/.ssh/.*
    
por 23.06.2011 / 16:08
0

Os diretórios precisam do conjunto de bits x (para o diretório em que o bit é visto como bit de pesquisa) para abrir. Então eu uso tree para que eu possa obter apenas o conjunto de pastas e evitar o pesadelo de ter todos os arquivos definidos como executáveis (a opção para a árvore é -d List directories only. ):

sudo tree -faid here_goes_your_directory xargs -L1 -I{} sudo chmod 755  "{}"

Atenção !!! você deve ter isso em consideração:

  • usando chmod ou chown recursivo no diretório raiz / ou diretórios do sistema destruirá seu SO (na verdade, qualquer coisa recursiva no diretório / ou nos diretórios do sistema é perigosa)

  • isso não é uma boa prática de segurança para definir permissões em massa como essas

por 25.01.2018 / 15:15