Pasta com APENAS permissão de gravação é inútil ... certo?

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?

permissions directory

— wmnorth
fonte

Pode ser que nem toda combinação seja útil. Por exemplo, em inglês, temos palavras, essas palavras são compostas de letras, nem todas as combinações formam palavras válidas. por exemplo aoeuidhtns

— ctrl-alt-delor 08/08

Desta forma, você não poderia, por exemplo, criar um arquivo? Você solicita ao espaço e ao inode do sistema de arquivos e depois de escrever o nome e o inode na sua tabela de diretórios. Você deve ter apenas o problema de ter 2 arquivos com o mesmo nome, mas inode diferente no mesmo diretório ...

— Hastur

@Hastur: Eu também pensei, mas depois que mkdir foo ; chmod 200 foo ; touch foo/bareu chego touch: cannot touch ‘foo/bar’: Permission denied. Isso acontece mesmo se foo / bar já existir. Estou testando no bash (Arch Linux).

— Wmnorth 8/08

Minha culpa foi que eu estava pensando que você estava reescrevendo do código-fonte do sistema ... não podemos ter dois arquivos com o mesmo nome no mesmo diretório, por isso é lógico que é proibido dar a possibilidade de criá-lo.

— Hastur

Sim, é inútil. A resolução do inode também requer "x" e "r", portanto, nos diretórios, mesmo um único "rw" é inútil.

— peterh - Restabelece Monica

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.

— Barmar
fonte

Esta analogia minha está correta ou é um grande erro?

Eu acho que está correto, você precisa de permissão wx para poder gravar em uma pasta.

Independentemente da resposta anterior, existe alguma situação em que é apropriado ter uma pasta com permissões conforme descrito?

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

root@leon:/media# mount -o umask=527,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/media# ls /media/pen/ -la
total 44
d-w-r-x--- 10 enforcer ftp  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

em seguida, com o aplicador do usuário, tente escrever um novo arquivo

enforcer@leon:~$ touch /media/pen/hola
touch: cannot touch ‘/media/pen/hola’: Permission denied

desmonte e remonte com wx

root@leon:/media# umount /dev/sdb1
root@leon:/media# mount -o umask=427,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/home/jjorge# ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer wim  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

tente novamente

enforcer@leon:~$ touch /media/pen/hola
enforcer@leon:~$ ls /media/pen/
ls: cannot open directory /media/pen/: Permission denied
enforcer@leon:~$ cat /media/pen/hola
cat: /media/pen/hola: Permission denied

ftp@leon:/home/jjorge$ ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer ftp  4096 Oct 20 10:20 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..
--wxr-x---  1 enforcer wim     0 Oct 20 10:20 hola

Com esta configuração, você agora pode escrever

— Javier Jorge
fonte