запросы и разбор файлов apache

Question

Я только что столкнулся с интересной ситуацией на работе, которая, черт возьми, задела мое понимание того, как apache2 выполняет php-файлы.

У меня сложилось впечатление, что apache2 определит правильный тип файла и запустит его через правильный анализатор файлов. Это позволило бы парсеру выполнить фактическое выполнение, и из-за этого я понял, что php-файлы, выполняемые apache, должны иметь только права на чтение.

пример:

возьми простой php файл с 744 правами

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

выполнение этого с ./test.php выдает разрешение, в котором отказано.

но выполнение его с /usr /bin /php test.php работает нормально.

измените права на 755, и он работает правильно с ./test.php

Похоже, это то же самое, что происходит, когда apache запускает файл. это возвращает запрещенную ошибку.

итак, наконец, вот вопросы.

Как apache на самом деле обрабатывает и передает запросы на файлы?

Как он передает файл правильному парсеру?

Зачем ему нужны права на исполнение? Очевидно, синтаксический анализатор не только читает файл, как я первоначально ожидал.

Будьте нежны, пожалуйста .. Я ДУМАЛ, что я знал это.

Answer 1

1) Выполнение perms для файла ничего не значит для apache. Это просто для ядра, чтобы знать, как выполнить файл, если вы попытаетесь выполнить его (скажем, через оболочку). Пока вы читали перманент, где apache может его читать, у вас все в порядке.

РЕДАКТИРОВАТЬ ПЕРЕДАЧИ Чтения были важной вещью - apache необходимо выполнить perms в каталогах вплоть до корня. Для каталога выполнить означает доступный для поиска, и для поиска файла apache необходимы поисковые запросы в каталоге.

2) Apache не «выдает» файлы. Это не выполняет их. У вас есть встроенный интерпретатор в Apache, который может обрабатывать файлы PHP. Это происходит в процессе Apache. Это настраивается следующим образом:

Вы добавляете модуль:

LoadModule php5_module        libexec/libphp5.so

Модуль скомпилирован / создан, чтобы знать, как бороться с парсингом php. Он связан с интерпретатором php и в основном состоит из связующего кода для PHP для взаимодействия с apache, как и ожидает apache. Модуль PHP определенно знает, как обращаться с двумя типами MIME:application/x-httpd-php и application/x-httpd-php-source . Итак, теперь вы должны сказать apache, как подключить php файлы к модулю. Обычно это делается с помощью:

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

Итак, теперь мы сказали apache передавать файлы .php процессору PHP. Идет ли по суффиксу единственный путь? Нет, вы можете настроить любые каталоги на наличие всех файлов PHP или всего сервера. Но это имеет смысл. Также обратите внимание, что нас не волнует линия Шебанга (#!/ USR / бен / PHP). Мы настроены только на расширение файла.

3) Хорошо, так почему у вас есть запрещенная ошибка? Я не знаю. Есть много причин, почему это может быть. Вы проверили журнал ошибок? У вас есть правильные права доступа в каталоге файловой системы, где процесс apache может читать каталоги вплоть до root? У вас есть правильные разрешения в файлах конфигурации? Я бы проверил журналы ошибок.

ВТОРОЕ РЕДАКТИРОВАНИЕ

Я думаю, что я понимаю вашу путаницу ...

Существует два способа генерации динамического контента через Apache. Один из них - через встроенный интерпретатор, такой как PHP. Perl и python также являются распространенными встроенными интерпретаторами. Веб-сервер загружает интерпретатор в процесс httpd с помощью модуля glue (mod_php, mod_perl и т.д.). Код не "выполняется", но он загружается, анализируется и интерпретируется в процессе httpd.

Второй способ - через CGI-скрипт. В этом случае апач делает выполнение файла. Клеем в этом случае являются переменные окружения (apache устанавливает некоторые флаги) и, возможно, стандартный ввод в скрипт. Чтобы отправить обратно в apache, вы отправляете контент на стандартном выходе, который apache добавляет световые декорации и отправляет клиенту, и вы отправляете ошибки на stderr, который apache добавляет в свой error_log. Спецификация CGI диктует правила работы этого "клея". В этом случае вы выполняете файл, поэтому права доступа к файлу важны для apache.

CGI встречается реже, чем раньше. Преимущества CGI в том, что это отдельный процесс от веб-сервера. Это не может причинить ему никакого вреда (ну, если анализировать вывод безопасно). Недостатками являются изоляция. Мне нужно форк /exec для каждого запуска (хотя есть схемы, называемые fastCGI, которые помогают в этом). PHP (среди некоторых других) также имеет другую модель кодирования, где вы добавляете немного кода в HTML вместо того, чтобы писать огромный скрипт и выталкивать HTML оттуда. Это облегчает работу большинства людей, что является большой причиной того, почему PHP так популярен в Интернете.