2002-08-14 16:12:46 UTC

UPDATE: Бурные дебаты по поводу securuty а точнее по поводу безопасности версии парсера скомпилированного без опции --disable-foreign-group-files, вынудили его разработчиков пуститься на изучение особенностей работы этого провайдера, и в связи с этим статья была серьёзно переделана по сравнению с первоначальным вариантом.

Итак, Константин Моршнев, — создатель технологии парсер, исследовал систему безопасности этого провайдера:

Концепция их безопасности в общем понятна и традиционна:

1. все, что делает пользователь запускается под suexec (кроме .php, который работает в своем safe mode). suexec UID — владелец, группа — «левая» — специальную группу, которая никуда не имеет прав.
2. Статика отдается apache работающим от UID httpd, GUID httpd. Пользователь apache в теории имеет доступ к вашим файлам (к которым может обратиться группа), и если бы были неправильно настроены права apache, то например через «include virtual» к ним было бы можно достучаться.

И если бы suexec не менял группу, то до файлов с правами группы на чтение можно было бы достучаться. Из смешных вещей у них убраны права на чтение (R) и оставлено только право для обращение по имени (X) для каталогов /, /etc/. Но зная имя файла, его аттрибуты все равно можно получить — например в результате можно сделать вывод, что на этой машине порядка 1500 аккаунтов.

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

То есть используемая в парсере схема проверки доступа по ID группы дает больше возможностей (если есть доступ к конфигурированию системы).

Но раз уж есть такие «неправильные» хостинги, то мы поддержим и их, добавив альтернативную проверку по ID пользователя. За исключением меньшей общности проблем безопасности эта схема тоже не создает и имеет право на жизнь.

Да, и на вопросы:

1. Т.е. там пользователь, от имени которого запускается скрипты, совпадает с пользователем который владеет файлами?
2. И вы идя нам навстречу можете реализовать эту схему в парсере, т.е. если имя пользователя в контексте которого работает скрипт, совпадает с именем пользователя владеющего файлами, то парсер прочтет эти файлы?

Последовало небольшое уточнение:

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

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

Поддержка данной схемы безопасности, т.е. чтение парсером файлов не только своей группы, но и своего пользователя, не заставила себя долго ждать и была реализована в версии 3.0007. Все версии парсера, младше указанной, по-прежнему приходится собирать без опции --disable-foreign-group-files.

Консоль управления БД и сайтом на net.ru хоть и нормально работающая (всё есть), но уж больно она куцая какая-то. Например на 350mb.ru она гораздо лучше, например для управления MySQL применяется phpMyAdmin, который получше нежели чем то, что есть в консоли на net.ru. Да и скрипт консоли управления входит в дисковое пространство которое вы занимаете, и таким образом отнимает у вас ещё 50 Кб, хоть и немного но тем не менее. Резервная копия базы тоже делается в ваше пространство и если объём базы превышает объём оставшегося вам места на диске, то резервное копирование нельзя сделать для всей базы сразу и придется его делать отдельно для одной или нескольких таблиц, что при наличии большого количества таблиц превращается в серьёзную проблему. В консоли управления сайтом отсутствует опция определения использования дискового пространства, т.е. вы не можете узнать не обращаясь в службу поддержки, сколько же у вас осталось свободного места до того как его лимит будет исчерпан, что весьма неудобно.

Но не всё так плохо, есть и плюсы — здесь при таком количестве сервисов. весьма низкие цены, и качество работы этих сервисов я бы охарактеризовал как очень хорошее. В качестве почтового сервера здесь применяется CommuniGate Pro — очень мощный, гибкий в настройке, имеющий мощные средства борьбы со спамом, надежный почтовый сервер. К плюсам можно отнести то, что здесь стараются обновлять ПО серверов (Apache, MySQL и т.д.) до последних версий практически сразу же после выхода последних стабильных версий этого самого ПО.

Работу других сервисов, кроме mySQL, как то, — PostgreeSQL, php, java сервлеты и др. я не проверял, если у вас есть желание вы можете сделать это сами.