Изоляция VirtualHost'ов

Сейчас так что-то делает? А вообще, раньше, вроде бы, разделением прав и группами решалось. Ну и фтп в чруте или типа того.

apache2-mpm-itk is an MPM module for the apache web server which allows you to run each of your virtual host under a separate uid and gid i.e. the scripts and configuration files for one virtual host are completely separated from that of others and therefore no longer have to be readable for all of them.

Хорошо, а в lighttpd есть такой функционал?

Не претендую на лучший ответ, но недавно меня попросили дать немного хостинга для WP одному сайтику. Я просто сделал:

• отдельного пользователя
• chroot ssh пользователю
• php-fpm тоже сделал под этого пользователя и запер его в домашнем каталоге
• логи, tmp и т.п. тоже все перенаправил в домашний каталог пользователя

Может что-то еще есть, пусть подскажут.

Хорошо, а в lighttpd есть такой функционал?

без понятия, можешь загуглить и нам рассказать.

В контейнеры суй.

Можешь ещё с suexec + Directory для апача повозиться

Есть проекты, где setuid для каждого виртуального хоста делается сильно лучше, чем ITK. Для этого в ядро Linux грузится модуль помогающий пользователю www-data делать setuid на определенный диапазон UID (владельцев виртуальных хостов apache). Обратное переключение делается стандартно за счет savedUID. Система состоит из модуля апаче, который определяет на какого пользователя нужно переключиться для данного VirtualHost и модуля ядра, который позволяет это делать пользователю www-data. В хуке apache на запись в лог делается возврат на www-data. Таким образом, для каждого пользователя виртуального хостинга делается свой пользователь и группа и все права разруливаются на уровне пользователей OS. В худшем случае злоумышленник сможет переключиться на любого пользователя виртуального хостинга (но без setuid апача это изначально так).

Когда-то я видел статью про такую схему, кажется на habr'е, но сейчас найти не смог. Однако за несколько лет до этого сам делал такую схему (идея лежит на поверхности). В моем случае модуль ядра после проверки, что текущий пользователь www-data, просто подменял savedUID на требуемый, после чего стандартный seteuid позволял менять пользователя и тот же seteuid менял его обратно после обработки запроса. Итого 3 системных вызова (подготовка - переключение пользователя - возврат пользователя, вызовы очень легкие) позволяли для каждого запроса устанавливать пользователя и менять его обратно на www-data. Модуль ядра был тривиальный, при его закрузке ему передавали три числовых параметра: UID www-data, минимальный и максимальный UID пользователей виртуального хостинга и он при вызове проверял, что текущий пользователь www-data, а требуемый в разрешенном диапазоне и в таком случае всего-лишь менял saved UID текущего процесса на требуемый (однако было это до того, как в seteuid завезли capabilities). Модуль апаче конфигурировал target UID для виртуального хоста по явно заданному параметру в конфигурации хоста либо по владельцу корневой папки виртуального хоста.

В общем, при желании такое можно написать и отладить без знакомства с программированием под ядро Linux где-то за неделю. Или найти готовое решение.

Ого! Весьма полезное дополнение.

К слову не об этой статье речь?

https://habr.com/ru/post/269835/

Похоже, она.

Ненужно, от словав вообще. Запиливается каждому пользователю своя виртуалка или свой контейнер, если у каждого юзера свой фиксированный IP - то он просто назначается виртуалке ли коннтейнеру, если адрес один или ощий пул - на вход вешается nginx или какой-нибудь haproxy.

Ну да, давайте профукивать ресурсы на вирутализацию...

Читайте по буквам: «каждому пользоателю своя виртуалка ИЛИ СВОЙ КОНТЕЙНЕР». Не хотите виртуалок - делайте контейнеры. Оверхеда там не особо много, а изоляция существенно лучше (и проще, потмоу что за вас уже всё сделали) чем луюбый шаманские пляски с виртуалхостами.

https://redmine.lighttpd.net/projects/lighttpd/wiki/HowToSetupFastCgiIndividu...

Статья из официальной документации Лайти. Предлагается под каждый виртуальный хост запускать отдельный FastCGI соккет, что в купе с грамотной настройкой прав доступа к каталогам файловой системы позволит обеспечить достаточный уровень безопасности.

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