В общем с одной стороны тема достаточно банальная, так как поднималась интернете не раз,но с другой стороны ответа на вопрос я так и не нашел.Нужен хостинг Apache+PHP+MySql. Сразу оговорюсь, на нем должны хоститься не только мои сайты, но и сайты клиентов, а значит самое-то подумать о безопасности.
PHP как я понял, из статей валяющихся в интернете, лучше настраивать не модулем, а CGI.
Каким образом организовать то, что бы один клиент не смог даже прочитать содержимое каталога другого?
Первая мысль которая напрашивается: Каждый пользователь owner для своей папки, так же папка принадлежит группе пользователей apache. Вроде нормально, но если пользователю в php-скрипте нужно будет записать что-то в файл? Окажется что у него нет доступа?
Так же в этом случае не знаю как быть с ограничением места под сайт. В ProFTPd еще как-то можно ограничить место, но давать юзерам доступ по ssh в этом случае крайне не рекомендуется. (хотя бы потому что они смогут зайти и почитать конфигурационные файлы в системе. Не будешь же для каждой папки в системе прописывать вручную запрещение "на чтение для всех"
Вариант второй.
Есть такая приблуда (не помню как зовется), которая эмулирует собственную файловую систему для каждого пользователя, т.е. у каждого юзера есть свой root со своими /var /etc /bin и т.д. В данном случае за root у него выйти никак не получиться. Можно даже давать доступ через ssh, т.к. он так же не выйдет за пределы своего дома. Правда, мне почему-то кажется, что этот способ более ресурсоемкий и из-за своей нестандартности может создать разные проблемы с настройкой apache, php, proftpd и наверняка создаст проблемы с прикручиванием какой-то админки-юзерпанели.Собственно буду очень признателен за различные мысли и рассуждения по этому поводу, к тому же думаю, что это будет полезно многим.
google://"apache suexec fastcgi php"
> google://"apache suexec fastcgi php"Вопрос был как-раз что не про fastcgi. Это для меня как-раз наиболее очевидный момент из всего этого
>> google://"apache suexec fastcgi php"
> Вопрос был как-раз что не про fastcgi. Это для меня как-раз наиболее
> очевидный момент из всего этогоСовершенно непонятный ответ. Вы по-русски писать можете ?
> Есть такая приблуда (не помню как зовется), которая эмулирует собственную файловую систему
> для каждого пользователя, т.е. у каждого юзера есть свой root со
> своими /var /etc /bin и т.д. В данном случае за
> root у него выйти никак не получиться. Можно даже давать доступ
> через ssh, т.к. он так же не выйдет за пределы своего
> дома. Правда, мне почему-то кажется, что этот способ более ресурсоемкий
> и из-за своей нестандартности может создать разные проблемы с настройкой apache,
> php, proftpd и наверняка создаст проблемы с прикручиванием какой-то админки-юзерпанели.Сложно сказать что имелось ввиду, но полные права пользователю и доступ через ssh можно дать только по средствам виртуальной среды на уровне ОС (Пример - Linux:OpenVZ, FreeBSD:Jail)
, ну или второй вариант по средствам chroot окружения, в нем можно создать все что душе угодно, я для доступа по ssh как раз удобно использовать OpenSSH у него достаточно удобно настраивается chroot окружение.Но если есть еще какие варианты, то тоже хотелось бы услашать)
>> Есть такая приблуда (не помню как зовется), которая эмулирует собственную файловую систему
>> для каждого пользователя, т.е. у каждого юзера есть свой root со
>> своими /var /etc /bin и т.д. В данном случае за
>> root у него выйти никак не получиться. Можно даже давать доступ
>> через ssh, т.к. он так же не выйдет за пределы своего
>> дома. Правда, мне почему-то кажется, что этот способ более ресурсоемкий
>> и из-за своей нестандартности может создать разные проблемы с настройкой apache,
>> php, proftpd и наверняка создаст проблемы с прикручиванием какой-то админки-юзерпанели.Еще раз перечитал первое сообщение и все же думаю что грамотно настроенный chroot решит поставленную задачу.
Виртуализация - несомненно хорошо, но это уже не совсем веб хостинг, а уже предоставление полноценной linux машины.Как-раз про chroot я и говорил, просто не смог вспомнить как он называется. Из-за подобного распределения, нагрузка на ОС не сильно увеличится?
В принципе в моей задачи не так сильно важен ssh доступ. Его можно и не давать, хотя его наличие всегда будет хорошим плюсом. Мне нужно отделить друг от друга пользователей, что бы ни при каких обстоятельствах один юзер не смог получить доступ к директории другого.
Так же интересует, что бы один пользователь не смог вызвать крах системы в целом, из-за порождения большого числа процессов, или из-за чего-то подобного.
> Виртуализация - несомненно хорошо, но это уже не совсем веб хостинг, а
> уже предоставление полноценной linux машины.мда, вы видимо совершенно не понимаете какую ерунду говорите ...
виртуализация, хостинг, фря, линукс, выделенный сервак - ацкая каша в голове
> Как-раз про chroot я и говорил, просто не смог вспомнить как он
> называется. Из-за подобного распределения, нагрузка на ОС не сильно увеличится?вы видимо не только не помните, но и не понимаете суть механизма - оверхен незначительный
> В принципе в моей задачи не так сильно важен ssh доступ. Его
> можно и не давать, хотя его наличие всегда будет хорошим
> плюсом. Мне нужно отделить друг от друга пользователей, что бы
> ни при каких обстоятельствах один юзер не смог получить доступ к
> директории другого.известны механизмы выхода из чрут окружения - jail в этом плане значительно надежней + безопасный рутовый ssh в песочницу - оверхед минимальный - проблема лишь с дисковым пространством
Большое спасибо. Так и сделаем
Вы же апач через виртуал хосты настраиваете? Добавьте тогда для каждого виртуал хоста такую штуку.
php_admin_value open_basedir "путь до сайта"
Смотрю что если ставить jail, то каждой клетке нужно назначать свой ip, хотя в моей задаче нужно что бы у сервака оставался один общий ip-адрес. Так же по всей видимости прийдется в каждую клетку ставить apache, mysql и т.д. т.е. никакого места не напасешся.Может все-таки chroot в этом плане лучше? Только ессно надо убрать у пользователя с папки /bin /sbin лишние файлы
Моя задача разделить доступ к файлам пользователей, т.е. что бы один юзер не смог прочитать файлы другого. Если же каждый виртуалхост засовывать в отдельный jail - это же убиться можно
Кстати, если верить мануалам, то каждая клетка собирается достаточно долго.
> Если же каждый виртуалхост засовывать в отдельный jail - это же убиться можно
> Кстати, если верить мануалам, то каждая клетка собирается достаточно долго.Феерично.
1. скопировать шаблон джейла и в него скопировать виртуалхост - дело пары минут
2. джейл под типовую задачу собирается лишь раз, затем копипастится
>> Если же каждый виртуалхост засовывать в отдельный jail - это же убиться можно
>> Кстати, если верить мануалам, то каждая клетка собирается достаточно долго.
> Феерично.
> 1. скопировать шаблон джейла и в него скопировать виртуалхост - дело пары
> минут
> 2. джейл под типовую задачу собирается лишь раз, затем копипаститсяне только феерично, но и архи-глупо!
афтар видимо не понимает, что хоть в чруте, хоть в жейле - если будет запускаться несколько индейцев - то они не уживутся на одном порту одного айпи!
Автор действительно не много понимает в chroot и jail, т.к. до этого с этим не приходилось иметь дел.На одном ай-пи уживаться не будут, тогда как-таки быть с хостингом, когда нужно что бы на одном сервере было много разных сайтов. У меня, конечно, есть пару внешних ипов от прова, но их хватит очень не на много
> На одном ай-пи уживаться не будут, тогда как-таки быть с хостингом, когда
> нужно что бы на одном сервере было много разных сайтов.Решений есть множество. Например, настраивается ДНС так, чтобы в мир для всех джейлов отдавался один общий адрес, а внутри имена разруливались по серым адресам.
>> На одном ай-пи уживаться не будут, тогда как-таки быть с хостингом, когда
>> нужно что бы на одном сервере было много разных сайтов.
> Решений есть множество. Например, настраивается ДНС так, чтобы в мир для всех
> джейлов отдавался один общий адрес, а внутри имена разруливались по серым
> адресам.можно на FE поставить nginx, и пробрасывать запросы в jails по внутренним айпишникам...
-----------
а можно мозг не парить, и поставить apache + suexec + fastcgi и php через fastcgi крутить.
памяти конечно экземпляры php поедят прилично, но от этого никуда не деться, если по jails разделить, то они поедят её еще больше. (Но внятно настроенный fastcgi будет прибивать ненужные процессы ;-)
ну и далее настроить права доступа
750 siteuser:www-data на /web/siteuser/,
750 root:siteuser на /var/log/hosting/siteuser(пользователь siteuser создается с группой siteuser, в www-data его включать не надо)
собственно, считаю что этого достаточно.
поставить nginx и перед этим "сервером приложений" - это по вкусу/по ситуации.
-------
можно схему поразвивать, например выделив несколько зон, в которых создавать такие апачи / пользовательские сайты, отделить внутреннние сайты-сервисы (вебмыло хостинга, пхпмайадмин и т п), вынести СУБДу отдельно, и т п....
Спасибо. Думаю что придется отказаться от jail в пользу этого решения. Правда и от ssh доступа тоже.Походу сделать хостинг на jail вроде бы хорошо (в плане секьюрности), но на каждую клетку свой ип - это накладно.
Я просто встречал такие хостинги, которые дают доступ и по ssh тоже. Там по-всей видимости было настроено как-раз таки через jail, т.к. были каталоги типа /etc /bin
> Спасибо. Думаю что придется отказаться от jail в пользу этого решения.
> Правда и от ssh доступа тоже.Я лично не вижу особых причин полностью отказываться от раздачи ssh. за вычетом дыр в ядре, особо критичного ничего не будет, при правильной раздаче прав и конфигурации сервера. Ну можно r снять с каталога /web, чтобы перечисления аккаунтов не было, как top ограничить чтобы показывал только процессы пользователя - тоже вопрос минимальный.
Не забудьте ограничения (лимиты) повыставлять на потребляемые пользователями ресурсы и память, (форк-бомбы, зажирание всей оперативы и тп).> Походу сделать хостинг на jail вроде бы хорошо (в плане секьюрности), но
> на каждую клетку свой ип - это накладно.ну так айпи - выдавайте внутренние, для доступа снаружи по ssh - проброс портов, естественно порт будет не 22. Про ftp доступ лучше забыть, как из-за того, что порты будут нестандартны и придет много головняка, так и из-за того, что это небезопасно.
Проброс веб-трафика - через nginx, который по имени веб-хоста отправит запрос на нужный внутренний айпи. Возможно, отдаст при этом статику напрямую (отчасти это не безопасно, поскольку в nginx нет проверки SymlinkIfOwnerMatch, но есть патч на эту тему (суть в том, что пользователь может создать симлинк в своем каталоге на файл, к которому он не имеет прямого доступа, предсказав его имя (типовая цмс-ка, к примеру) и запросить его содержимое как прямой запрос к файлу своего сайта)).
> Я просто встречал такие хостинги, которые дают доступ и по ssh
> тоже. Там по-всей видимости было настроено как-раз таки через jail, т.к.
> были каталоги типа /etc /binВариантов километры =)
Хорошо, на счет ssh с разграниченными правамиПредположим есть директория
/var/wwwв ней есть папки юзеров
vasya_site
petya_site
masha_siteУ каждой папки owner соответственно vasya, petya, masha
на директорию www стоит доступ rwx r-x --x
На каждую директорию пользователя rwx r-x ---Соответственно каждый каталог для юзера является домашним. Т.е. начинает он свой путь именно оттуда. По-идее он не имеет возможности попасть в директорию /var/www (проверял), но если он сделает chdir / или chdir /var (/usr) то он перейдет соответственно в соответствующую директорию. Можно конечно отобрать права на чтение "для всех" на все директории, но боюсь что могут возникнуть вопросы у приложений. Во всяком случае папку /bin прийдется оставить, т.к. иначе он не сможет даже вызвать chdir, да и с /bin/sh у него будут проблемы. А в таком случае возникнут вопросы, что он сможет вызвать что-то, что не должен.
Поэтому решение давать ssh не отделяя окружение - не очень хорошая идея. В моей задаче правда рядовым юзверям ssh не нужен, но есть пару знакомых кому было бы очень желательно дать ssh. Специально они буровить конечно не будет, но у меня никакого желания давать им возможность шариться по всему серваку