Com o Bash sourceé possível executar um script sem um bit de execução definido. Este é um comportamento documentado e esperado, mas não é contra o uso de um bit de execução?
Eu sei, isso sourcenão cria um subshell.
Responder1
sourceou o equivalente, mas padrãoponto.não execute o script, masleros comandos do arquivo de script e, em seguida, execute-os, linha por linha, no ambiente shell atual.
Não há nada contra o uso de bit de execução, pois o shell só precisalerpermissão para ler o conteúdo do arquivo.
O bit de execução só é necessário quando vocêcorrero roteiro. Aqui o shell terá fork()um novo processo usandoexecve()função para criar uma nova imagem de processo a partir do script, que deve ser um arquivo executável regular.
Responder2
Bash é um intérprete; ele aceita entradas e faz o que quiser. Não é necessário prestar atenção ao bit executável. Na verdade, o Bash é portátil e pode ser executado em sistemas operacionais e sistemas de arquivos que não possuem nenhum conceito de bit executável.
O que se importa com o bit executável é o kernel do sistema operacional. Quando o kernel Linux executa um exec, por exemplo, ele verifica se o sistema de arquivos não está montado com uma noexecopção, verifica o bit executável do arquivo do programa e impõe quaisquer requisitos impostos pelos módulos de segurança (como SELinux ou AppArmor).
Observe que o bit executável é um tipo de controle bastante discricionário. Em um sistema Linux x86-64, por exemplo, você pode ignorar a verificação do bit executável do kernel,invocando explicitamente /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2como intérprete:
cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls
Isso é um tanto análogo ao fornecimento do código-fonte do Bash no Bash, exceto que ld.soé o intérprete e o código que ele executa é o código de máquina no formato ELF.
Responder3
O bit executável (ao contrário do resto) em arquivos nonsetuid e nonsetguid não é um mecanismo de segurança. Qualquer coisa que você possa ler, você pode executar indiretamente, e o Linux permitirá que você leia indiretamente qualquer coisa que você possa executar, mas não leia diretamente (isso deve ser suficiente para abrir um buraco no conceito de x-bit não definido (g) uid ser um medida de segurança).
É mais uma questão de conveniência: deixe o sistema executá-lo diretamente para mim se o bit estiver definido, caso contrário, preciso fazer isso indiretamente ( bash the_script;ou algumhackear para obter a imagem de memória de um executável sem permissão de leitura).
Você pode configurá-lo por conveniência se pretende inserir e executar seu insurcable.
Aparentemente, no entanto, muitos implementadores de bibliotecas compartilhadas compartilham seu pensamento e, conseqüentemente, muitos sistemas exigem que as bibliotecas compartilhadas, que são essencialmente o equivalente nativo dos insourcables shell, sejam marcadas como executáveis para serem utilizáveis. VerPor que as bibliotecas compartilhadas são executáveis?.
Responder4
No que diz respeito ao sistema operacional, um arquivo contendo script de shell é apenas dados. Se você passar o nome de tal arquivo de dados para o sourcecomando ou passá-lo na linha de comando para uma invocação do shell bash, tudo o que o sistema operacional vê é uma string que coincide com o nome de um arquivo contendo dados.
Como o bit de execução seria relevante nesse caso?