Tendo trabalhado com Linux há anos e me encontrando com algum tempo livre, decidi revisar alguns conceitos básicos. Então, reli as coisas sobre permissões (sem verificar o código-fonte) e seus casos especiais para pastas, e criei uma nova maneira (pelo menos para mim ...) de pensar em permissões de pasta (para um usuário específico / group / others): imagino uma pasta como uma tabela com duas colunas, assim:
filename | inode
foo | 111
bar | 222
A permissão de leitura significa que você pode ler (e listar) a coluna esquerda da tabela, a permissão de gravação corresponde à adição e remoção de entradas na tabela e a permissão de execução corresponde à capacidade de converter do nome do arquivo para o inode; ou seja, você pode acessar o conteúdo da pasta.
Fiz algumas experiências e todos os resultados são consistentes com essa "visão de mundo" minha, mas uma conclusão parece inevitável: que uma pasta com permissões d-w-------é totalmente inútil. Elaboração: você não pode listar seu conteúdo, não pode ler nenhum arquivo que você conheça (porque não pode traduzir nomes em inodes), não pode remover ou renomear ou adicionar arquivos, porque novamente isso implicaria tradução , e você nem pode adicionar links físicos (porque, suponho, isso significaria adicionar um nome e um número de inode, o que significa que você conheceria os dois, o que, por sua vez, suponha que viola o objetivo de desabilitar a permissão de execução) . E, claro, se não são arquivos dentro de uma tal pasta, então você não pode excluir essa pasta também, porque você não pode excluir seu conteúdo.
Então ... eu gostaria de fazer duas perguntas:
- Esta analogia minha está correta ou é um grande erro?
- Independentemente da resposta anterior, existe alguma situação em que é apropriado ter uma pasta com permissões conforme descrito?
fonte
mkdir foo ; chmod 200 foo ; touch foo/bareu chegotouch: cannot touch ‘foo/bar’: Permission denied. Isso acontece mesmo se foo / bar já existir. Estou testando no bash (Arch Linux).Respostas:
Sua compreensão é praticamente correta. Uma maneira melhor de pensar na permissão de execução é que ela permite que você faça coisas com um nome de arquivo ou diretório no diretório (além de apenas ler o próprio nome). A maioria dessas coisas envolve a tradução do nome para um inode, mas também inclui a criação de novos nomes e a remoção de nomes existentes.
A permissão de gravação no diretório sem execução é, portanto, bastante inútil, pois não há nada que você possa escrever se não puder acessar os arquivos nele.
fonte
Eu acho que está correto, você precisa de permissão wx para poder gravar em uma pasta.
Você pode ter um processo que grava informações em uma pasta e outra as consome, mas é necessário impedir que o gravador leia outras informações armazenadas naquele local.
A situação descrita anteriormente é útil em unidades de imposição automática de velocidade. Essas unidades devem passar por um processo de verificação em que o oficial do estado deve minimizar as possibilidades de adulteração. Algumas unidades automáticas de controle de velocidade têm um cartão de memória sd externo, onde o sistema armazena registros de violação. Mas também pode armazenar um arquivo de configuração "mágico" que altera ilegalmente o comportamento da unidade verificada. Portanto, o processo que grava o registro de violação não deve poder ler nada do cartão de memória sd.
Aqui está um exemplo, primeiro apenas com gravação, e depois como fazê-lo funcionar com o wx:
Monte um dispositivo
em seguida, com o aplicador do usuário, tente escrever um novo arquivo
desmonte e remonte com wx
tente novamente
Com esta configuração, você agora pode escrever
fonte