Не скажи... Писал плагин на ограничение числа файлов для пользователей ISPmanager 5, в итоге наблюдал интересную картину. cl-quota --user=имя_пользователя -H 100000 -S 100000 выдавало пользователь не найден. Писало так только для пользователей, которые были созданы через ISPmanager. Пообщавшись с поддержкой CloudLinux, сказали, что поддержки панели ISPmanager 5 с их стороны нет, они её только вот-вот добавили и порекомедовали обновить lve-utils из тестового репозитория, что помогло. Ошибка была вроде бы в том, что cl-quota искала список пользователей и тарифов (это файл /etc/container/user_plan.cache, а там было на подобии error: unknown panel).
А что с CageFS и Apache ITK пока непонятно... несколько лет работала такая связка, правда Apache ITK брал не из пакетов, а собирал из исходников с патчем от CloudLinux.
Я не специалист по безопасности, но как писал ранее - спится гораздо спокойнее, если даже /etc/passwd для пользователей закрыт :)
В ISPmanager 4 знаю, что если стоит проксирование и запросы в панель обрабатываются NGINX, то пароли всех пользователей светятся в /var/log/nginx/access.log, в 5 версии вроде бы всё хорошо в этом плане.
Речь идет об обходе ограничения CageFS, а не о чтении файлов другого пользователя. За счет выставленных прав в указанной Вами документации прочитать чужой каталог действительно невозможно, но полазить по системе - вполне можно за счет обхода CageFS.
Также, если я верно понимаю, то в случае, если запрос не попадает в LVE, перестают работать ограничения установленные для пользователя на процессор, память, число соединений и процессов, что тоже не хорошо :)
Я вчера и сегодня общался с поддержкой CloudLinux, они подтвердили наличие проблемы конкретно на моём сервере. Также сказали, что клиентов с ISPmanager 5 у них мало и к ним пока с данной проблемой никто не обращался. В понедельник пообещали продолжить исследование работы подняв свою тестовую площадку. /usr/sbin/httpd.itk из их пакета с необходимыми патчами, Вы правы, V(o)ViK.
В режиме Apache Prefork работает корректно, запросы погружаются в LVE, в режиме ITK запросы не уходят в LVE из-за чего не работает CageFS.
Затрагивает ли Вас проблема можно проверить путем запуска команды:
cat /var/log/messages | grep "Can't enter lve from a slave context"
Если увидите сообщения вида:
Значит Вы под угрозой.
У меня зашло без проблем. Проверьте антивирус, фаервол, может что-то блокирует доступ. Хотя, может новый Anti-DDoS так работает...
Значит касается только CentOS 6.
На CentOS 6, после конвертации системы (локальный узел) в файле /etc/sysconfig/httpd есть строка HTTPD=/usr/sbin/httpd.itk, apachectl -V выдает Server MPM: ITK, в top соответственно висят процессы /usr/sbin/httpd.itk, yum provides /usr/sbin/httpd.itk выдает Repo: epel. rpm -qa | grep httpd действительно выдает httpd-2.2.15-53.el6.cloudlinux.x86_64, но он не используется.
Система ставилась на прошлой неделе.
Они проверяют доступность сервера пингом, проверьте, стабилен ли он и пингуется ли вообще сервер.
Проблема внутри Вашего сервера. Никаких ежедневных проблем нет, вот Вам график из MUNIN за месяц (дергает сервер из вне каждые 5 минут):
А вот за последнюю неделю:
Поясню - белые пробелы, это сервер недоступен из вне. Итого - две проблемы за последние 30 дней :)
Такое есть у многих дата центров. Например, когда была обнаружена SSLv3 POODLE, то некоторые дата центры сканировали свои сети и высылали уведомления о том, что их ресурсы подвержены уязвимости.
