razão para adicionar permissões de execução a um script de shell

Question

É um fato bem conhecido que, se alguém quiser executar um script no shell, o script precisa ter permissões de execução:

$ ls -l
total 4
-rw-r--r-- 1 user user 19 Mar 14 01:08 hw
$ ./hw
bash: ./hw: Permission denied
$ /home/user/hw
bash: /home/user/hw: Permission denied
$

No entanto, é possível executar este script com bash <scriptname> , sh <scriptname> , etc:

$ bash hw
Hello, World!
$ 

Isso significa que basicamente é possível executar um arquivo de script, mesmo que ele tenha apenas permissões de leitura. Esta talvez seja uma pergunta boba, mas qual é o sentido de dar permissões de execução para um arquivo de script? É unicamente porque, para que um programa seja executado, ele precisa ter permissões de execução, mas na verdade não acrescenta segurança ou outros benefícios?

    

Answer 1

Sim, você pode usar bash /path/to/script , mas os scripts podem ter intérpretes diferentes. Seu possível script foi escrito para trabalhar com ksh , zsh ou talvez awk ou expect . Assim, você precisa saber com qual intérprete usar para chamar o script. Ao criar um script com um executável shebang line (que #!/bin/bash no topo), o usuário não precisa mais saber qual interpretador usar. Ele também permite colocar o script em $PATH e chamá-lo como um programa normal.

    

Answer 2

O recurso de segurança está na combinação com o bit suid / sgid, mas continue lendo.

Exec bit alone agora é principalmente uma conveniência - mostra quais arquivos devem ser executados diretamente.

• ao digitar comandos, arquivos sem exec não são executados no diretório atual, se você tiver "." no seu PATH
• O preenchimento automático de tabulação pode sugerir apenas arquivos com exec bit se ele vir que você está digitando um nome de comando
• os usuários podem ver melhor quais arquivos devem ser executados
• diz ao kernel que o arquivo cujo nome o usuário digitou é um comando e o kernel deve se preocupar em abri-lo e descobrir o que é o carregador / executor.

Mas isso não impede que um usuário dedicado execute o arquivo, como outros já mostrados.

O truque é que quando você pode contornar o (falta de) bit exec ao executar o arquivo com um carregador explícito, você também não usa seu bit suid / sgid, para que você não obtenha privilégios elevados.

Vamos ter em / bin

 -rwsr--r-- root root some_privileged_command

Você pode executar o comando como um usuário sem privilégios com

 $ /lib/ld-linux.so.2 /bin/some_privileged_command

mas não será executado com permissões de root, ao contrário de

 -rwsr-xr-x root root other_privileged_command

que, se você executá-lo diretamente como

 $ /bin/other_privileged_command

Dito isto, é discutível comandos shebang de qualquer maneira, porque eles não serão executados com root perms mesmo com suid set - para isso, o próprio executável do shell precisaria desse bit (e seria muito, muito ruim de fazer isso.