solicitações e análise de arquivos do apache

Question

Acabei de me deparar com uma situação interessante no trabalho que disparou para o inferno minha compreensão de como o apache2 executa arquivos php.

Fiquei com a impressão de que o apache2 determinaria o tipo de arquivo correto e o executaria por meio do analisador de arquivos correto. Isso permitiria que o analisador fizesse a execução real e, por causa disso, entendi que os arquivos php executados pelo apache precisavam apenas de direitos de leitura.

exemplo:

pegue um arquivo php simples com 744 direitos

#!/usr/bin/php
<?php
echo "test";
?>

executando isso com ./test.php emite uma permissão negada.

mas executá-lo com / usr / bin / php test.php funciona bem.

altera os direitos para 755 e executa corretamente com ./test.php

Isto parece ser o mesmo que acontece quando o apache executa o arquivo. está retornando um erro proibido.

então finalmente ... aí vem as perguntas.

Como o apache realmente manipula e repassa solicitações de arquivos?

Como ele entrega o arquivo ao analisador correto?

Por que precisa executar direitos? Obviamente, o analisador não está apenas lendo o arquivo como eu havia antecipado originalmente.

Seja gentil, por favor .. Eu achava que eu sabia disso.

    

Answer 1

1) As permissões de execução no arquivo não significam nada para o apache. Isso é apenas para o kernel saber como executar o arquivo se você tentar executá-lo (digamos, através do shell). Contanto que você tenha lido perms onde o apache pode lê-lo, você está bem.

EDIT os perms de leitura eram o mais importante - o apache precisa executar perms nos diretórios até a raiz. Para um diretório, executar significa pesquisável e o apache precisa de perms de pesquisa no diretório para procurar o arquivo.

2) O Apache não "passa" os arquivos. Não os executa. Você tem um interpretador embutido no apache que pode manipular arquivos PHP. Isso acontece dentro do processo do apache. Ele é configurado dessa maneira:

Você adiciona o módulo:

LoadModule php5_module        libexec/libphp5.so

O módulo é compilado / criado para saber como lidar com a análise php. Ele está vinculado ao interpretador php e consiste basicamente em código de cola para o PHP falar com o apache, da maneira que o apache espera. O módulo PHP sabe especificamente como lidar com dois tipos MIME, application/x-httpd-php e application/x-httpd-php-source . Então, agora você precisa dizer ao apache como conectar arquivos php ao módulo. Isso geralmente é feito com:

<IfModule mod_php5.c>
   AddType application/x-httpd-php .php
   AddType application/x-httpd-php-source .phps
</IfModule>

Então, agora nós dissemos ao apache para passar os arquivos .php para o processador PHP. Vai pelo sufixo o único caminho? Não, você poderia configurar qualquer diretório para ter todos os arquivos PHP ou o servidor inteiro. Mas isso faz mais sentido. Além disso, observe que não nos importamos com a linha shebang (#! / Usr / bin / php). Estamos configurados apenas para extensão de arquivo.

3) OK, então por que você tem o erro proibido? Eu não sei. Existem muitas razões pelas quais isso poderia ser. Você já verificou o log de erros? Você tem o perms apropriado no diretório do sistema de arquivos, onde o processo do apache pode ler diretórios até o root? Você tem os perms apropriados nos arquivos de configuração? Eu checaria os registros de erros.

SEGUNDA EDIÇÃO

Acho que entendi sua confusão ...

Existem duas maneiras de gerar conteúdo dinâmico por meio do apache. Uma é através de um interpretador embutido, como o PHP. Perl e python também são intérpretes embutidos comuns. O servidor web tem o intérprete carregando no processo httpd, usando um módulo de cola (mod_php, mod_perl, etc). O código não é "executado", mas é carregado, analisado e interpretado dentro do processo httpd.

A segunda maneira é através de um script CGI. Nesse caso, o apache executa o arquivo. A cola, nesse caso, é a variável de ambiente (o apache define alguns sinalizadores) e, possivelmente, a entrada padrão para o script. Para mandar de volta para o apache, você envia o conteúdo no padrão, que o apache adiciona decorações de luz e envia para o cliente, e você envia erros no stderr, que o apache anexa ao seu error_log. A especificação CGI dita as regras sobre como essa "cola" funciona. Neste caso, você está executando um arquivo, então as permissões de execução no arquivo são importantes para o apache.

CGI é menos comum do que costumava ser. As vantagens do CGI são que é um processo isolado do servidor web. Ele não pode causar nenhum dano a ele (bem, contanto que analise a saída com segurança). As desvantagens são o isolamento. Eu preciso de fork / exec para cada execução (embora existam alguns esquemas chamados fastCGI que ajudam nisso). O PHP (entre outros) também tem um modelo de codificação diferente, onde você adiciona um pouco de código ao HTML, em vez de escrever um script enorme e extrair o HTML de lá. Isso torna mais fácil para a maioria das pessoas escrever, o que é uma grande parte do motivo pelo qual o PHP é tão popular na web.