Eu tenho uma pasta de projeto que possui permissões confusas em todos os arquivos. Tive a má tendência de definir tudo para permissões octais 777 porque isso resolveu todos os problemas não relacionados à segurança. Em seguida, uploads de FTP, arquivos criados por editores de texto etc. têm seu próprio conjunto de permissões, tornando tudo uma bagunça. Decidi me recompor e começar a usar as permissões da maneira como deveriam ser usadas.
Achei que 664 era um bom padrão para todos os meus arquivos e pastas, e apenas removeria as permissões de outras pessoas em arquivos privados e adicionaria +x para arquivos executáveis.
No segundo, mudei minha pasta do projeto para 664:
$ sudochmod -R664. $ls ls: não é possível abrir o diretório.: Permissão negada
O que não faz sentido para mim. Tenho permissões de leitura/gravação e sou o proprietário da pasta do projeto. A parte mais à esquerda da ls -lpasta do meu projeto é assim:
-rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r--3 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 4 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ...
Presumo que isso tenha algo a ver com as permissões nos diretórios, maso que?
Responder1
O bit de execução é necessário para percorrer um diretório *nix. Você não pode cdentrar em um diretório para o qual não tenha permissões de execução, e isso afeta vários utilitários de maneiras não óbvias, se eles precisarem de um contexto de diretório. Considerar:
$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo
# You can read the contents of the directory, but ls still complains.
$ ls foo
ls: cannot access foo/bar: Permission denied
bar
# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied
A razão para tudo isso é a maneira como stat() funciona. Extraído de man 2 stat:
Nenhuma permissão é necessária no arquivo em si, mas - no caso de stat() e lstat() - a permissão de execução (pesquisa) é necessária em todos os diretórios no caminho que levam ao arquivo.
O resultado final é que um recursivo chmodraramente fará o que você espera e causará estragos nas permissões de leitura e execução do diretório que podem levar a resultados inesperados como o seu. Sempre trate as permissões de diretório separadamente das permissões de arquivo para obter melhores resultados.
Responder2
Você precisa de permissões de execução nos diretórios.
Considerar
sudo find -type d -exec chmod +x {} +
Atualização: aqui está minha racionalização sobre esse uso, aparentemente estranho, de permissões de execução.
O Unix (e, portanto, o Linux) trata praticamente tudo como arquivos. Isso se estende a discos e a vários outros dispositivos. também inclui diretórios.
Os sistemas de arquivos Unix tradicionais possuem um conjunto de permissões que se aplicam aos arquivos. Portanto, os designers do Unix tiveram que encontrar algo útil para cada bit de permissão quando aplicado a um "arquivo" que não era seu arquivo de dados normal.
Vamos considerar diretórios. Inicialmente, parece razoável usar apenas a permissão de leitura para decidir se alguém pode acessar o diretório - por exemplo, para produzir uma lista dos arquivos nele contidos e seus tamanhos e carimbos de data, etc.
No entanto, suponha que você queira que usuários comuns possam executar programas em /usr/local/bin, mas não queira que eles possam vasculhar em /usr/local para ver o que há lá. Se você tiver apenas permissão de leitura, não poderá evitar isso.
Portanto, a permissão de execução, de outra forma redundante, foi usada para controlar se o seu shell tem permissão para "atravessar" um diretório, com o que queremos dizer, não descubra mais nada do que é necessário para encontrar e ler os detalhes de um subdiretório como parte de um caminho. Isto permite que você acesse o diretório /usr/local apenas o necessário para ler o conteúdo de /usr/local/bin.
Então +x em /usr/local significa que você pode executar "/usr/local/bin/foo" Mas +r em /usr/local significa que você pode descobrir tudo o que está em /usr/local incluindo quem o possui, quais permissões cada arquivo tem, qual era o tamanho etc.
O que foi dito acima é baseado em vagas lembranças e suposições. Pode não ser exatamente verdade, mas acredito que dá uma ideia razoável de por que “executar” significa “capaz de atravessar”.