O Apache 2.2 não está obedecendo às permissões cgi de nível de arquivo

Question

Eu tenho dois atendentes. O servidor 1 executa o Apache 2.2 e o mod_perl 2.0.4. O servidor 2 executa o Apache 2.0 e mod_perl 1.99. Eles têm arquivos conf quase idênticos. A seção perl do vhost se parece com isso:

<Location/perl>
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options +ExecCGI
</Location>

Se eu colocar um script cgi no diretório perl designado do Servidor 2 chmodded para 644, não consigo acessar o arquivo através do navegador da web. Eu recebo Proibido como o erro. Esse é o comportamento que eu esperaria. Eu tenho que chmod-lo para 755 primeiro.

No entanto, se eu colocar o script de salvar no diretório para scripts cgi no Servidor 1, chmodded para 644, o servidor apenas executará o script. Não parece se importar com quais permissões do arquivo são apenas para o diretório definido.

Todos os arquivos são de propriedade e agrupados em root e o apache está sendo executado em um usuário separado. O diretório é chmodded 755 e também pertence ao root.

A minha pergunta é, existe uma maneira de tornar o comportamento idêntico e isso é um risco potencial de segurança no servidor 1? Ou há uma maneira geralmente melhor que eu deveria estar fazendo isso?

    

Answer 1

mod_perl não é CGI, então nem + ExecCGI nem permissões executáveis são realmente importantes para ele. A razão pela qual você vê um comportamento diferente é que na versão 1.999_02 mod_perl os desenvolvedores mudaram de idéia sobre o bit executável:

ModPerl::Registry no longer checks for -x bit (we don't executed
scripts anyway), and thus works on acl-based filesystems. Also
replaced the -r check with a proper error handling when the file is
read in. [Damon Buckwalter <[email protected]>]

Em link

    

Answer 2

Se o Apache for informado pela opção ExecCGI de que pode executar um cgi em um diretório, ele será. Normalmente, um script perl não precisa ser executável para o Apache rodá-lo, apenas legível. É possível que a versão 1.99 mais antiga do mod_perl implemente algo como o Apache 'XBitHack', mas esse comportamento agora não é padrão. Você está dizendo que o diretório que lhe deu um erro 403 foi 644? Ninguém além do root pode navegar em um diretório 644, portanto, isso é esperado. Mas se você está dizendo que o arquivo é 644, e o diretório é pelo menos 111, então o motivo para o erro 403 pode ser o 'XBitHack' ou algo mais difícil de determinar a partir das informações fornecidas.

O comportamento mais recente é mais seguro e flexível, porque geralmente é uma boa ideia minimizar as permissões de todos os objetos do sistema de arquivos, e scripts não executáveis localizados em um diretório ExecCGI são executáveis apenas pelo Apache. Se você não quer que eles sejam, não os coloque lá ou não defina a opção ExecCGI. Se por algum motivo você quiser que eles sejam também executáveis pelo shell, você pode definir o bit.