O que o sinalizador NOEXEC significa ao montar diretórios no RHEL?

Estou tentando entender o sinalizador NOEXEC ao montar.

Estou tendo um problema de execução no diretório / tmp em outra máquina que não consigo acessar atm onde o diretório / tmp está montado em uma unidade diferente de '/' e NOEXEC está presente. Eu queria tentar recriar esse cenário na minha máquina, mas não tenho um segundo disco rígido. Eu tentei fazer o seguinte comando:

mount --bind /test1 /test2

Em seguida, removi o bindsinalizador e adicionei o NOEXECarquivo / etc / fstab. Então, eu criei um arquivo em / test2 chamado test.sh, onde ele reproduz 'olá mundo'. Eu tento executá-lo e ele disse 'permissão negada'. Eu executei chmod 777 test.she consegui executar o arquivo muito bem. Eu pensei que o sinalizador NOEXEC não deveria me permitir executar nada?

Não mount --bind /test1 /test2é o mesmo que montar a partir de uma unidade física completamente diferente? Como em / test1 e / test2 estão em unidades diferentes?

— user972276
fonte

Eu suspeito que você pode ser vítima de alguma peculiaridade do mount mount. Veja esta resposta .

— Kamil Maciorowski

A opção 'NOEXEC' flag no mountcomando não permite a execução de binários executáveis no sistema de arquivos montado ¹ . No entanto, quando um script (um arquivo de texto que começa com a linha she-bang; ou seja, uma linha que começa com #!) é fornecido a alguns shells (bash), ele executa o executável nomeado nessa linha (por exemplo, /usr/bin/perl) e passa o caminho do script de shell como o primeiro argumento. O intérprete real pode não estar nesse ponto de montagem.
__________
¹ O mountcomando normalmente monta um sistema de arquivos . (Pode-se bindargumentar que loopback ou montagens podem ser consideradas uma exceção a essa generalidade.) Em alguns casos (por exemplo, /tmp), esse sistema de arquivos conterá apenas um diretório.

— KJ4IPS
fonte

Portanto, embora o arquivo sh esteja em / test2, ele está sendo executado em / bin / sh, não em / test2? Na outra máquina, há um processo java que grava scripts de shell no diretório / tmp e os executa. Acho que me lembro dos scripts de shell que ele está criando #!/bin/shno topo. Eu não sei como o script shell está sendo executado, exceto por passar por java e referências / bin / sh. Se estiver referenciando / bin / sh e o diretório bin tiver privilégios de execução, por que os scripts shell não seriam executados como no meu teste?

— user972276

Tudo depende da chamada do shell / programa, os scripts do shell não são ELFs e não podem ser executados diretamente; no entanto, alguns shells não permitirão a execução de um script em um FS montado no NOEXEC; eles simplesmente morrerão. Não tenho certeza de qual é o comportamento do / bin / sh nesse caso. (Especialmente porque eu não sei qual você está usando, existem alguns sabores).

— KJ4IPS 12/03

Venha para pensar sobre isso, quando você usa o shell, o sistema percebe o #! e chama o interpretador apropriado (/ bin / bash /tmp/file.sh), mas se o bit java estiver apenas chamando (/tmp/file.sh), isso não funcionará.

— KJ4IPS

a instância java não está no diretório / tmp e precisaria usar um intérprete para executar scripts de shell, certo? A menos que o java tenha essa funcionalidade embutida, o que significa que a execução ainda não aconteceria no diretório / tmp.

— user972276

Na minha opinião, sua resposta afirma erroneamente que é o trabalho do shell ler um shebang. Veja esta resposta .

— Kamil Maciorowski