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.she, em seguida, o bash tenta abrir hw.shpara 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 readpermissão para executar um arquivo - apenas executepermissã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 executepermissão. No * BSD-systmes, vários executáveis dão executepermissã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 readpermissão (e apenas executepermissã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 readpermissã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- readnem- writepermissão ao proprietário, mas às vezes pode ser uma boa idéia impedir que ownerapenas 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 chmodpermissão no arquivo.
ownerapenas 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}/mapse 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.)