Inversão de permissão relativa à execução de scripts de shell

1

Digamos que alguém tenha um script de shell chamado Foo.sh em seu diretório de trabalho atual. Ele lê como

#!/bin/bash
#some scripts below

Para executar o script digitando "./Foo.sh", ele precisa de permissão de execução com ele. Em vez disso, ele pode escolher executar o script simplesmente fazendo "bash Foo.sh", passando o script como um argumento para programar o bash. Neste último caso, ele só precisa de permissão de leitura.

Isso parece uma inversão de permissão para mim, ou seja, um usuário pode executar um executável que ele não tem permissão para executar.

Minha pergunta é:

  1. Este é um design intencional que tem alguma solidez por trás dele, ou um problema legado, preservado apenas por razões de compatibilidade?

  2. Isso tem algumas implicações de segurança?

por John Z. Li 09.03.2018 / 02:21

3 respostas

2

Este é um dispositivo de conveniência. A linha shebang codifica o intérprete no roteiro. Além da conveniência, também é informativo, da mesma forma que a extensão do arquivo. Você ainda pode executá-lo com qualquer outro intérprete:

bash script.undefined

ou

sh script.undefined

ou possivelmente

perl script.undefined

etc.

Em termos de segurança, é a mesma coisa. Em ambos os casos, o arquivo é lido e executado com o ID de usuário efetivo do usuário ativo. A parte pegajosa não tem efeito para idiomas interpretados, mas isso é outra história . (Na verdade, esse bit é importante para as implicações de segurança).

    
por 09.03.2018 / 02:55
0

Tecnicamente funciona como deveria ser. Quando você corre

./foo.sh

Você está executando o programa foo.sh (com ajuda do shebang)

Mas quando sua corrida

bash foo.sh

tecnicamente você está executando o programa bash (/ bin / bash ou / usr / bin / bash).

Se você está preocupado com segurança. Imagine que o usuário tenha acesso de leitura de foo.sh e o usuário copie o conteúdo de foo.sh para bar.sh , o qual ele possui execute access . Assim, em todos os casos, se o usuário puder ler arquivos .sh , ele poderá executá-lo facilmente.

    
por 09.03.2018 / 07:52
0

É apenas uma consequência do velho ditado de que "os dados de um homem são um programa de outro homem". Os computadores são construídos com base no Von-Neumann-Architecture, e isso significa que não há nada inerente aos arquivos que dizem "isto é um executável e o outro não". Qualquer texto em prosa que você escreve pode agir como um programa quando interpretado por um intérprete adequado.

Portanto, se um arquivo contém informações que precisam ser ocultadas, você precisa protegê-lo. A proteção de execução não ajuda. Mesmo se você tiver um programa compilado, que você executa proteção, mas não proteção contra leitura, eu posso facilmente executá-lo. Eu só preciso copiá-lo, definir a permissão de execução na cópia e pronto.

Portanto, se você deseja segurança, é necessário remover a permissão de leitura, não a permissão de execução, do arquivo e do diretório em que o arquivo está localizado.

    
por 09.03.2018 / 08:46