Por que a permissão de execução não é necessária para originar um arquivo? [duplicado]

Question

Alguém perguntou uma pergunta sobre o Ask Ubuntu sobre por que eles receberam permission denied quando eles entraram em um shell Bash

/etc/profile

Eu sei que isso acontece porque o arquivo não tem permissão de execução. Mesmo root não pode executá-lo ( sudo /path/to/file/with/no/execute/bits falha com o erro não informativo sudo /path/to...: command not found ). Eu também sei que o root pode entrar em um diretório sem bits de execução, então a proibição absoluta de executar arquivos não-executáveis parece especial. No bate-papo, Eliah Kagan opinou que o motivo pelo qual a raiz não poderia executar arquivos não executáveis era proteger a raiz (presumivelmente, a execução acidental de códigos perigosos).

Eu brevemente me perguntei por que alguém iria querer executar /etc/profile e achava que, se alguém quisesse executá-lo, ele provavelmente iria querer source it (porque é um arquivo de configuração que define variáveis de ambiente e shell) . Então percebi que a permissão de execução não é necessária para source de qualquer arquivo regular. Mas source executa o arquivo no shell atual! O arquivo pode conter qualquer comando e . file seguirá em frente e executará.

Se a permissão de execução estiver restrita para evitar a execução acidental de código potencialmente perigoso, por que é possível executar arquivos não-executáveis usando o comando source ?

    

Answer 1

Não acredito que a execução de um arquivo não executável falhe de propósito para impedir a execução acidental de um código potencialmente perigoso. É apenas parte da semântica de execve : falha com EACCES se “permissão de execução for negada para o arquivo ou um script ou interpretador ELF”. (Estou citando o Linux execve manpage . POSIX diz algo semelhante:" A permissão de pesquisa é negada para um diretório listado no prefixo de caminho do novo arquivo de imagem de processo ou o novo arquivo de imagem de processo nega a permissão de execução. ") Unix / Linux nunca esteve particularmente preocupado em impedir que os usuários explodem seus próprios pés.

Acho que a explicação é bem mais prosaica: as especificações para execução e fornecimento são diferentes. A execução direta pede ao kernel para executar um determinado comando e que impõe privilégios de execução. O fornecimento de um arquivo é especificado apenas como leitura e execução; na verdade, a bash manpage afirma explicitamente que “o arquivo               procurado em PATH não precisa ser executável. " POSIX diz “ Ao contrário do normal comando search, no entanto, o arquivo procurado pelo utilitário dot não precisa ser executável. ”( . é equivalente a source .)

Observe que você pode executar binários mesmo quando eles não são executáveis, usando uma técnica semelhante à sua origem:

$ cp /bin/ls .
$ chmod 644 ls
$ /lib64/ld-2.26.so ./ls

Kusalananda 's ponto sobre como comparar bash ' source e POSIX . é interessante. No modo não POSIX, se source receber um argumento sem um caminho, ele tentará encontrá-lo no PATH e, se não encontrá-lo, procurará no diretório atual; no modo POSIX não, porque o POSIX proíbe isso:

Some older implementations searched the current directory for the file, even if the value of PATH disallowed it. This behavior was omitted from this volume of POSIX.1-2008 due to concerns about introducing the susceptibility to trojan horses that the user might be trying to avoid by leaving dot out of PATH.

Isso não muda muito na discussão, já que um argumento com um caminho será processado por source ou . em qualquer caso. (E realmente você deve sempre usar um caminho, mesmo que relativo, para source arguments, para evitar surpresas ao tentar source algo que é também no seu PATH . Tente criar um arquivo chamado test e obtendo isso com source test em bash para ver o que quero dizer.)