по умолчанию да, но сею возможность легко можно убрать, как, я намекнул ранее, расписывать полностью все конфиги (я ещё умалчиваю про самописные скрипты) я не буду
п.с. мне очень смешит Ваше отношение ко всем вопросам (если я в чём-то уверен, это так), странно что сам факт отсутствия понимания вопросов и знаний Вами воспринимается как невозможный :)
это сейчас модно стало видимо... писать что хостинг настолько уникален, что способен размещать CMS, обычный маркетинг...
я не путаю, сипанель собирает два пхп, один для апача, второй для системы, ОБА работают на базе вышеуказанных настроек
п.с. впрочем на самом деле там их куча используется в сипанеле, но речь шла только про то, что доступно юзеру
Вы видимо просто не работали с suPHP, так как на лицо факт непонимания разницы между работой suPHP и других CGI режимов... php -c свой-конфиг.ini -f скрипт.php обработается с ИГНОРИРОВАНИЕМ данного ini файла (будет использован php.ini, заданный в настройках suPHP)
используется
<Location />
suPHP_ConfigPath
есть соответствующие средства у suPHP
бред писать глупости, magick quotes можно включить или выключить для отдельного аккаунта (то есть создаётся php.ini по умолчанию для всех и есть php.ini (внимание!) созданный специально для конкретного пользователя (пути к обоим php.ini жёстко прописаны, как-то изменить путь нельзя, загрузить свой php.ini нельзя, точнее можно, но он будет игнорироваться системой)
так лицензия Plesk с неограниченным кол-вом доменов или с ограничением до 100 доменов? Разница в цене будет почти в 2 раза
5.4 сейчас в альфа стадии
http://php.net/
PHP 5.4 includes new language features and removes several legacy (deprecated) behaviors
п.с. 5.3 рано или поздно ставить придётся, просто по той причине, что 5.2 более не поддерживается разработчиками...впрочем если 5.4 выпустят в пределах ближайшего года, тогда возможно стоит сразу на эту версию перейти, сейчас пока ради совместимости нет смысла уходить от 5.2 в сторону 5.3
ТС, уточните пожалуйста требования на ЦПУ/ОЗУ/порт(трафик)
Защита (как верно ранее заметили) должна быть комплексная, другое дело, что на базе suPHP (но именно на базе, а не за счёт исключительно разницы в режимах) построить более безопасную среду намного проще (безопасную для всего сервера, но да, к сожалению не для того аккаунта, который был взломан). Как минимум нужно сделать (но именно при использовании suPHP):
1) Отключаем глобально в php.ini ВСЕ ф-ции, кои могут быть использованы для повышения прав (exec, system и т.д.)
2) Ограничиваем путь, по которому апач будет искать php.ini (дабы не было возможности загрузить свой php.ini с разрешёнными ф-циями)
3) Используем CloudLinux + CageFS + Grsecurity (разграничение доступа процессов пользователя к системной среде ОС)
4) Используем mod_security (с правилами соответствующими)
п.с. но сам по себе suPHP ненамного более безопасен, чем любой другой режим (если в системе есть публично известные уязвимости в ядре, той же glibc и т.д. повысят привилегии и вперёд с песней)
