Установка PHP как CGI работающий под suEXEC

Установка Apache, suEXEC и PHP как CGI

Версии софта:
    - apache_1.3.27rusPL30.16
    - php-4.2.3

Проблема
--------

Апач запускается от имени www:www, также запускаются и скрипты
клиентов. Это приводит к тому, что скрипт клиента не имеет прав
создавать и изменять файлы в своей же домашней папке. Поэтому
приходилось создавать папки/файлы с правами записи для всех или с
владельцем www. Такая же проблема и с PHP скритами, т.к. mod_perl4,
вкомпилённый в апач работает от его же владельца.

Другая проблема - доступность системных файлов и файлов других
клиентов из CGI и PHP скриптов. Многие системные файлы можно прочитать
простейшим скриптом, т.к. они доступны для чтения всем. Все файлы
клиентов доступны для чтения другим клиентам, но кроме этого для
изменения доступны те файлы/папки, которым мы сами и назначили
соответствующие права, чтобы клиент мог работать с ними из своих
скриптов.


Решение
-------

suEXEC позволяет запускать скрипты от имени владельца сайта и
соответственно создавать/менять файлы, принадлежащие ему. Поэтому нет
необходимости назначать право записи группе и тем более всем. К
сожалению проблема с чтением чужих файлов остаётся. Насколько я понял
её можно решить только с помощью виртуальных машин jail для каждого
виртуального хоста (сайта) причём с индивидуальными IP-адресами,
деревом необходимых файлов и библиотек и фиг его знает ещё чем.

Запуск PHP как CGI, а не как модуль Апача решает проблему и с PHP,
т.к. он запускается через suEXEC, такой метод немного усложняет
настройку для нас, но для клиентов проблем не добавляет. Включение
safe_mode для PHP-интерпретатора позволяет исключить чтение/изменение
файлов, не принадлежащих клиенту.

Установка и настройка

1. в папке с исходниками php сделал:
    ./configure \
        --with-gd=/usr/local \
        --with-ttf=yes  \
        --with-gettext \
        --with-zlib=/usr
        --enable-force-cgi-redirect
    make
    make install

2. в папке с апачем сделал:
    ./configure \
        --enable-suexec \
        --suexec-docroot=/usr/local/apache/htdocs \
        --suexec-userdir=/usr/local/apache/htdocs \
        --suexec-logfile=/usr/local/apache/logs/suexec.log \
        --suexec-caller=www
    make
    make install

В конфиге Апача надо, по меньшей мере, поменять параметры:
    User www
    Group www

Пример настройки виртуального хоста:

    User pupkin
    Group webusers
    ServerAdmin admin@pupkin.elcat.kg
    DocumentRoot /usr/local/apache/htdocs/pupkin
    ServerName pupkin.elcat.kg
    ScriptAlias /cgi-bin/ "/usr/local/apache/htdocs/pupkin/cgi-bin/"
    AddType application/x-httpd-php .php .php3
    Action  application/x-httpd-php /cgi-bin/php
    DirectoryIndex index.php index.shtml

Содержимое cgi-bin:

    /usr/local/apache/htdocs/pupkin/cgi-bin > ls -l
    total 3437
    -rwxr-xr-x  1 pupkin  webusers  3468792 27 апр 15:56 php
    -rw-r--r--  1 pupkin  webusers    37862 27 апр 15:57 php.ini



Обязательные условия при заведении новых клиентов
-------------------------------------------------

Общие

Пользователей для веба заводить только в соответствующую группу,
например webusers. Эта группа указана в файле /etc/ftpchroot, чтобы по
фтп не могли подняться выше своей домашней папки. Кому надо,
выставлять квоты командой:
    edquota -u username

Домашние папки клиентов должны принадлежать им и группе webusers,
права на запись должны быть только у владельца, но не у группы и тем
более не у всех.


Для suEXEC

Домашние папки пользователей должны быть только в каталоге
`/usr/local/apache/htdocs`. Т.к. только для скриптов из этой папки
(рекурсивно) действует suEXEC.

И скрипты, и папка cgi-bin должны принадлежать клиенту.

При настройке виртуального хоста в Апаче, кроме обычных, указать
параметры:
    User user_name
    Group webusers

Например:
    User pupkin
    Group webusers
    DocumentRoot /usr/local/apache/htdocs/pupkin
    ServerName pupkin.elcat.kg
    ...

Логи, касающиеся suEXEC, пишутся в файл `/usr/local/apache/logs/suexec.log`.


Для PHP

Для каждого клиента, которому нужен PHP, в конфиге виртуального хоста
указать следующие строки:
    ScriptAlias /cgi-bin/ "/usr/local/apache/htdocs/pupkin/cgi-bin/"
    AddType application/x-httpd-php .php .php3
    Action  application/x-httpd-php /cgi-bin/php

Эти строчки указывают Апачу при обращении к файлам с расширением .php
или .php3 отдавать их интерпретатору /cgi-bin/php. Вызов же
интерпретатора напрямую из строки URL запрещён при компиляции PHP
параметром "--enable-force-cgi-redirect".

В папку cgi-bin положить интерпретатор PHP и конфиг для него php.ini,
причём и папка и интерпретатор должны принадлежать самому клиенту, а
иметь возможность редактировать конфиг он не должен, т.е. конфиг
должен принадлежать root-у.

В файле php.ini нужно по меньшей мере включить безопасный режим -
"safe_mode = On".

Ко всему прочему мы можем включать безопасный режим не для всех сайтов
сразу, как было при mod_php, например можно выключить безопасный режим
для некоторых служебных сайтов.


Заключение
----------

Осталась только проблема с доступом к чужим файлам из CGI-скриптов
клиентов.

Вроде всё, надеюсь возникшие проблемы можно будет решить.

_________________________________________________________________
Дополнение

Проблему с чтением файлов других пользователей при помощи CGI-скриптов
можно решить при помощи правильно выставленных прав. Схема простая -
каждый пользователь входит в свою группу (например pupkin:pupkin и
vasya:vasya), пользователь, от имени которого запускается Апач, также
имеет свою группу (например www:www), все файлы доступны для
редактирования только владельцам, а для чтения - только группе,
остальным - ничего (640).

Для того, чтобы Апач смог прочитать файлы пользователей он должен
входить в каждую группу, вот пример из /etc/group:
    pupkin:*:1001:www
    vasya:*:1002:www

Чтобы при создании файла права сразу присваивались какие нам надо в
данном случае, можно поменять значение параметра umask в файле
/etc/login.conf. По-умолчанию umask=022 и значит созданные файлы будут
доступны для чтения всем, а если это папка, то ещё и будет право на
запуск для всех. Мы можем поменять это значение на 027 и никто кроме
владельца и группы не будут иметь прав на чтение созданного файла.
Только не забудьте запустить команду "cap_mkdb /etc/login.conf". Маска
применяется к правам с помощью операции логического умножения с
отрицанием.

Малик /20040112/