Início / unix / Perguntas / 419599
Accepted
Zanna
Asked: 2018-01-26 05:11:05 +0800 CST

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

  • 772

Alguém fez uma pergunta no Ask Ubuntu sobre por que eles obtiveram permission deniedquando entraram em um shell Bash

/etc/profile

Eu sei que isso ocorre porque o arquivo não tem permissão de execução. Mesmo o root não pode executá-lo ( sudo /path/to/file/with/no/execute/bitsfalha com o erro não informativo sudo /path/to...: command not found). 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 o root não seria capaz de executar arquivos não executáveis ​​era protegê-lo (presumivelmente, de executar códigos perigosos acidentalmente).

Eu brevemente me perguntei por que alguém iria querer executar /etc/profilee pensei que se alguém quisesse executá-lo, provavelmente iria querer source(porque é um arquivo de configuração que define as variáveis ​​de ambiente e shell). Percebi então que a permissão de execução não é necessária para sourcenenhum arquivo regular. Mas sourceexecuta o arquivo no shell atual! O arquivo pode conter qualquer comando e . fileirá em frente e executá-lo.

Se a permissão de execução for restrita para impedir a execução acidental de código potencialmente perigoso, por que é possível executar arquivos não executáveis ​​usando o sourcecomando?

bash permissions

1 respostas

  1. Best Answer

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

    Acho que a explicação é bem mais prosaica: as especificações de execução e sourcing são diferentes. A execução direta pede ao kernel para executar um determinado comando e isso impõe privilégios de execução. O fornecimento de um arquivo é apenas especificado como lê-lo e executá-lo; na verdade, a página de bashmanual declara explicitamente que “O arquivo procurado PATHnão precisa ser executável”. POSIX diz “Ao contrário da pesquisa de comando normal, no entanto, o arquivo pesquisado 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

    O argumento de Kusalananda sobre comparar ' bashs sourcee POSIX .é interessante. No modo não-POSIX, se sourcefor dado um argumento sem caminho, ele tenta encontrá-lo no PATH, e se não encontrar, procura no diretório atual; no modo POSIX não, porque o POSIX proíbe isso:

    Algumas implementações mais antigas procuravam o arquivo no diretório atual , mesmo que o valor de PATH não o permitisse. Esse comportamento foi omitido neste volume de POSIX.1-2008 devido a preocupações sobre a introdução da suscetibilidade a cavalos de tróia que o usuário pode estar tentando evitar deixando dot fora de PATH .

    Isso realmente não muda muito na discussão em questão, já que um argumento com um caminho será processado por sourceou .em qualquer caso. (E realmente você deve sempre usar um caminho, mesmo que apenas relativo, para sourceargumentos, para evitar surpresas quando tentar sourcealgo que também está em seu PATHarquivo . Tente criar um arquivo nomeado teste forneça-o com source testin bashpara ver o que quero dizer.)

    • 4

relate perguntas