Qual é o objetivo das permissões do Linux, como 111 ou 333 (ou seja, o usuário pode executar , mas não pode ler o arquivo), se a capacidade de executar não implica automaticamente a capacidade de ler?
Qual é o objetivo das permissões do Linux, como 111 ou 333 (ou seja, o usuário pode executar , mas não pode ler o arquivo), se a capacidade de executar não implica automaticamente a capacidade de ler?
Respostas:
Eu brinquei com ele e, aparentemente, permissões executivas não implicam permissões de leitura. Os binários podem ser executáveis sem serem legíveis:
$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw
hello world
$ cat hw
/bin/cat: hw: Permission denied
Porém, não consigo executar scripts, a menos que tenham os bits de permissão de leitura e execução em:
$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied
/bin/bash hw.sh
e, em seguida, o bash tenta abrir hw.sh
para leitura (e falha).
faz sentido para diretórios, por exemplo, se você mantiver executáveis (secretos) em um diretório específico e permitir que os usuários chamem esses arquivos sem poder ver o conteúdo do diretório (mas sabendo que um arquivo específico existe depois que você os informou!). 333 comparado a 111 permite gravar / excluir arquivos de / para esses diretórios sem poder ver o conteúdo do diretório.
Obviamente, nem todas as combinações são úteis, mas para usar a que você mencionou especificamente ... Na verdade, você não precisa de read
permissão para executar um arquivo - apenas execute
permissão - a menos que o arquivo em questão seja um script (por exemplo, um shell-script ( .sh
), script perl ( .pl
) e assim por diante). Binários normais podem ser executados apenas com a execute
permissão. No * BSD-systmes, vários executáveis dão execute
permissão sem permissão read
, especialmente em comandos "importantes para a segurança" - por exemplo su
.
Então, por que não dar aos usuários read
permissão (e apenas execute
permissão)? Como um arquivo que não pode ser lido por um usuário, também não pode ser copiado por esse usuário! A remoção da read
permissão evita que os usuários façam suas próprias cópias "pessoais" de executáveis - que eles poderão mais tarde abusar (por exemplo, obter SUID=root on
).
E não ter write
-permission, impede que um arquivo seja excluído com precisão.
Lembre-se de que não é permitido conceder nem- read
nem- write
permissão ao proprietário, mas às vezes pode ser uma boa idéia impedir que owner
apenas o arquivo seja excluído . É claro que o owner
- para não mencionar root
- sempre pode contornar essas medidas, se não de outras maneiras, e simplesmente pela chmod
permissão no arquivo.
owner
apenas o arquivo seja excluído." - exceto que você não precisa de nenhum tipo de permissão em um arquivo (leitura, gravação ou execução) para excluí-lo.
/proc/${PID}/maps
e lendo as seções relevantes da memória /proc/${PID}/mem
? Ou restringir as permissões no arquivo do executável também restringe as permissões de leitura em suas seções relevantes na memória durante a execução? (Este último parece improvável, IMO.)