Os scripts podem ser executados mesmo quando não estão definidos como executáveis?

Parece que consigo executar scripts (.sh) com e sem que eles sejam definidos como executáveis. Então, onde exatamente isso importa?

Digamos que você tenha o arquivo que myscriptcontém o seguinte:

#!/bin/bash
echo "Hello, World!"

Se você tornar este arquivo executável e executá-lo ./myscript, o kernel verá que os dois primeiros bytes são #!, o que significa que é um arquivo de script. O kernel usará o restante da linha como intérprete e passará o arquivo como seu primeiro argumento. Então, ele roda:

/bin/bash myscript

e o bash lê o arquivo e executa os comandos que ele contém.

Portanto, para que o bash (ou qualquer outro interpretador que seu script exija) "execute" o script, ele precisa apenas ler o arquivo.

Portanto, para scripts, o bit de execução apenas torna um pouco mais conveniente executá-lo. Desde que o bash seja executável, você sempre pode executar o bash com o arquivo de script como argumento ou executar o bash interativamente e copiar e colar a linha de script por linha no seu terminal para executar os comandos.

Verifique se você não está confundindo "executando o shell script" com "execute um shell script usando sh".

Isso não será afetado pelas permissões de arquivo em file.sh:

sh file.sh

Você está executando sh(que resolve o programa /bin/sh), que lê file.she executa seu código.

As permissões de arquivo terão efeito se você realmente executar o próprio script :

./file.sh

Observe que as permissões de arquivo não são suportadas por sistemas de arquivos não Linux, como o FAT. Portanto, mesmo se você executar chmod -x file.sh, o arquivo ainda terá suas permissões anteriores.

A permissão de execução é imposta pelo sistema de arquivos. Mas os programas também podem "executar" o código lendo o conteúdo do arquivo, o que ignora as permissões do sistema de arquivos em "execute".

Não pense nisso dessa maneira. Posso executar este arquivo? Pense nisso da seguinte maneira: Quem pode executar este arquivo?

Se o computador é seu e o arquivo é seu, tenho certeza que você pode executá-lo. Você pode querer procurar mais em comandos como chmod e chown e permissões de arquivo.

Espero que ajude.

O execsyscall do kernel do Linux falha EACCESse o arquivo não for executável

Enquanto você pode fazer sh myprog.sh(que apenas lê os arquivos e interpreta), tentar executar o programa como ./myprog.shnão pode funcionar, desde quando você faz isso:

• seu shell Bash no terminal usa a execchamada do sistema./myprog.sh
• os shebangs são interpretados diretamente pelo exec chamada do sistema do kernel do Linux, conforme explicado em: /programming/2429511/why-do-people-write-the-usr-bin-env-python-shebang-on -a-primeira-linha-de-um-pyt / 40938801 # 40938801
• o kernel do Linux se recusa a executar arquivos sem permissão executável

Isso pode ser verificado com main.c :

#define _XOPEN_SOURCE 700
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    char *argv[] = {"myprog", NULL};
    char *envp[] = {NULL};
    int ret;
    ret = execve("myprog.sh", argv, envp);
    perror("execve");
    printf("%d\n", errno);
    printf("%d\n", EACCES);
}

e myprog.sh :

#!/bin/sh
echo worked

Se myprog.shnão for executável,main falha com:

execve: Permission denied
13
13

Testado no Ubuntu 17.10 gcc -std=c99,.

O POSIX 7 menciona que em:

As funções exec, exceto fexecve (), falharão se:

[EACCES] A permissão de pesquisa é negada para um diretório listado no prefixo do caminho do novo arquivo de imagem de processo ou o novo arquivo de imagem de processo nega a permissão de execução.

Uma justificativa adicional pode ser encontrada em: /security/66550/unix-execute-permission-can-be-easily-bypassed-is-it-superfluous-or-whats-the