Как запретить пользователям читать файлы друг у друга

вместо монтирования можно просто делать hard линки

да

всё равно новые копии апача запускаются довольно часто

скажем, на каждые 10 соединений новый демон

конечно, на сайтах с нулевой посещаемостью немного потеряем - демоны будут простаивать

Можно. Например, на Хайвее (по крайней мере так было 2 года назад) апач пускается из-под вашего логина, соответственно он может менять права на все файлы. Допустим в сайте есть "маленькая" дыра, позволяющая загрузить исполняемый код на сервер. Если права стоят правильно (исходники не доступны для записи от имени web-сервера), то, возможно, сайт останется невредимым. Но если все файлы принадлежат пользователю, от имени которого работает web-сервер, то права на файлы силы иметь не будут.

тогда получаем систему, которая обновляется не на автомате через какой-нибудь apt-get или yum, а исключительно вручную.

Эмм, весь /usr /include /bin и т.д. пофайлово в хардлинки для каждого аккаунта,

когда их допустим сотня на сервер.. Плюс обновление, замена библиотек.

Да там с простым обновлением libmysqlclient'а подохнешь перехардлинковывать не говоря уже о обновлении системы и нагрузке на файловую систему. Жесткий подход выйдет.

Ужос!:) Это кто вам так настроил? MaxRequestsPerChild обычно стоит 10000,

это 1 чайлд на 10 тысяч запросов. Если у вас рождается на 10 коннектов 1 демон,

то в 1 коннект выливается 1000 запромов?! Ну поставьте MaxRequestsPerChild 0,

оно вообще не будет перезапускать чайлды.

Пусть на шаред 100 хостов. 10 посещаемые, 90 посещаемые радко.

1 тяжелый апач занимает мегабайт 10, тоесть если пускаем только рожалки,

то 90x10=900 мегабайт у вас уйдёт только на эти пустышки которые будут простаивать.

Красота.. А ведь после 1-го коннекта родится ещё и чайлд, и он будет висеть пока их число не превысит лимит. Даже по 1 штуке на 90 апачей у вас 1800 мегабайт только на пустые апачи которые простаивают.

Оно не даст записать файл, а прочитать? =)

Если апач имеет права на то чтобы прочесть файл, то может легко уйти достаточно важная инфа.

А Вы хотите автономный завод по производству бабла?

Патчить всё равно много чего приходится.

Например, Postfix без патчей квоты не поддерживал (может, и сейчас не поддерживает), что ж теперь не пользовать им?

Тем более патч занимает как правило 3-4 лишних команды с консоли...

Вот это уже правильный подход =)

Патчить апач на предмет смены uid/gid после того как рожалка рождает чайлда.

Тогда и mod_php будет жить от клиентского юзера..

А если подпатчить ядро, то можно много других вкусностей получить на которые намекал kostich.

Мне ближе другая схема, chroot юзеров в их дереве. При этом и апач отлично работает,

и юзер ну никак не вылезет за пределы своего хом рута =)

Решение для FreeBSD:

Делаем отлельное дерево:

#!/bin/sh

D=/usr/JAIL/SHARE

cd /usr/src

mkdir -p $D

make installworld DESTDIR=$D

cd etc

make distribution DESTDIR=$D

далее его монтируем через mount_nullfs или nfs, кому как удобно

в какой-то каталог, например /usr/JAIL/null/user с правами рид онли.

Монтируем поверх него /usr/JAIL/home/user в /usr/JAIL/SHARE/usr/local/www

Патчим апач, который при старте чайлда меняет ему uid/gid, черутим в

/usr/JAIL/null/user.

Патчик можно найти в сети (на вскидку http://fido.online.kz/files/apache_1.3.33.uid-chroot.patch) или поставить например модуль:

http://www.palsenberg.com/index.php/plain/projects/apache_1_xx_mod_suid

Всё, апач отлично работает, все файлы у него есть.

При этом получаем полное дерево файлов на r/o и каталог юзера с правами на запись,

по которому он спокойно может гулять =)

Однако выше chroot'а он не поднимется. И не прочитает/изменит каталоги/файлы соседей.

Никаких оверхедов по диску, никаких проблем с 1 юзер = 1 апач.

Аналогично туда-же черутится ssh, ftp, etc =)

http://httpd.apache.org/docs/2.0/mod/perchild.html

ответ утвердительный 😂 😂 😂 скажите, какая система поддерживает это сразу же после установки дистрибутива 😂

Ну речь про вебсервер идет. Почтовый сервер -- отдельный тазик, пусть админ этого тазика и заморачивается с патчами ;) а вот по определенным причинам некоторые вебсерверы приходится самому рулить, поэтому поневоле начнешь такими вопросами задаваться... Трудности еще заключаются в том, что свободных серваков, чтобы все поставить, оттюнить, а потом туда проекты заливать, нету. Т.е. все работы надо выполнять на серверах, на которых достаточно нагруженные проекты выполняются, поэтому для ошибки шансов нет. Если что-то не запустилось хотя бы в минимально рабочем режиме, сразу же откат на предыдущую конфигурацию.

вместо запуска apache для каждого юзера, можно запускать fastcgi сервера и только когда они нужны