Проблема с Suhosin / Hardened PHP
 

У меня хостинг на сервере с установленным Suhosin / Hardened PHP, настройки Suhosin / Hardened PHP не позволяют мне вносить изменения в движок форума(хаки, модули), причём до установки Suhosin / Hardened PHP всё устанавливалось и работало нормально, а сейчас при попытках внести какие либо изменения в движок выдаёт ошибку:
Эта ошибка может произойти из-за действия Suhosin / Hardened PHP, если он установлен на вашем сервере. Если вы знаете, что Suhosin запущен на вашем сервере и у вас есть доступ к конфигурации PHP, то попытайтесь увеличить значения следующих переменных:
php_value suhosin.post.max_vars
php_value suhosin.request.max_vars

Хостер честно признаётся, в том что Suhosin / Hardened PHP установил, и, принципиально, не собирается вносить какие либо изменения. Менять хостера я не хочу - слишком много плюсов для меня, которые я не могу получить на других хостингах.
На форуме поддержки движка форума приведены методы устранения проблемы - в частности написание файла .htaccess для корневых папок public_html и движка форума, и некоторых папок форума, но таким образом проблема не решается(у некоторых пользователей срабатывает, у некоторых нет).

Суть вопроса - имеются ли ещё какие нибудь методы "дезактивации" функции Suhosin / Hardened PHP в отношении отдельно взятого домена на сервере - где эта хрень установлена?

Стучать админу (лучше кирпичем по голове) и требовать убрать кривые патчи.

Этот сухосин-патч случит причиной кучи багов с непонятной причиной, поэтому устанавливать его следует лишь перед увольнением с нелюбимой работы.

Что делать пользователям? Требовать, чтобы поставили пхп без кривых патчей. Или менять хостера.

ССЗБ.

Сама по себе система Suhosin нифига не кривая! И даже ставится по умолчанию вместе с PHP5 во всех FreeBSD системах из портов (cd /usr/ports/lang/php5 && make config). А это значит что мантейнер из команды php.net считает это правильным. Также обратим внимание на репутацию автора Suhosin Patch, он сам нашел много ошибок в интерпретаторе PHP. Значит вещь действительно нужная!! Мне попадалось много эксплоитов, которые актуальны только если не установлен Suhosin / Hardened PHP Patch. А вот недовольных пользователей - ТС первый случай.

+1 за
php_value suhosin.post.max_vars
php_value suhosin.request.max_vars

в .htaccess ДОЛЖНО работать (обязательно убедиться что имеет эффект, использовать phpinfo и прочие информационные функции. Если не имеет, значит имеется ограничение AllowOverride, значит специалисту хостера необходимо прописать php_value/php_admin_value непосредственно в секции VirtualHost твоего домена в httpd.conf).

Поэтому хостера по башне действительно стучать нужно, система должна быть абсолютно настраиваема.

А следом за хостером можно потрясти изготовителей движка форума, знают ведь что не работает, только ничего не делают. Может движок сменить если проект на стадии старта?

При установке этого патча появляется ряд дополнительных настроек в php.ini с рядом дефолтных значений. На моих серверах индивидуальные настройки PHP для каждого хоста. Таким образом я разруливаю все проблемы тех, у кого они появляются (с Suhosin проблем не было).

Я больше доверяю php.net, чем сторонним поделиям ;)
А из-за сабжа есть проблемы - факт.

Нер, мантейнер порта сам из php.net =) Так доверяй))

Проблемы есть, но это не проблемы, а неудобства. Я столкнулся с тем, что мне для eAccelerator нужно парочку строчек в конфиг добавить для совместимости с Suhosin. Разве это проблема? ;) Проблемы есть у хакеров, у которых сплоит не отрабатывает из-за Suhosin :p

Меняй... на какую нибудь нормальную систему. просто сухосин лагает очень у многих..(((((((((((((

Даже на моем опыте есть проблемы с ним. не говоря уже о том, что доверяю я не только своему ;)

Это для админа неудобства, что у него руки кривые. А для тех, кто пользуется услугами такого админа - это проблема.
Встречалось такое при развертке приложений(нормальных), что не работали. После удаления сабжа(первым делом проверил наличие кривых патчей) они начинали работать. Выводы я сделал. Ты мне доверяешь в этом плане?)

хз :D

С какими приложениями у тебя трабл вылез? Сдаётся мне что это было нежелание разработчика подстроить своё приложение под безопасное окружение. А значит гнилая поддержка своего творения. Конечно, кто-то может подумать, здесь должна быть золотая середина. Разработчик Suhosin должен пойти на встречу разработчикам приложений, а разработчики приложений на встречу политике Suhosin. Но на самом деле, вопросы безопасности - это не территория компромисов.
Неправильно называть "кривым поделием" то что оффициально лежит в портах, репозиториях и реально повышает безопаность системы. Тот кто плюет на безопасность обычно наступает на последствия плевка или в это наступит тот кто находится по соседству)) Очень актуально на Shared хостингах, где даже хостинг могут взять протестить сплоит. Такая моя точка зрения.

Нер, а вот php-fpm это кривой патч или нет?

Это мое приложение.
А еще в пхп нет "безопасного окружения", есль "окружение с ограничениями возможностей". И мое приложение достаточно безопасно, чтобы через него что-то поломали и натворили.
Если на серваке есть другие приложения и у кого-то разыгралась паранойа - то пусть их чрутят, ограничивают и т.д.

Оно не только повышает, но и ставит дополнительные ограничения.
Представь ситуацию: пишешь скрипт, отдаешь заказчику, а он тебе: "А у нас он не работает потому что мы VasyaPupkin's Protector поставили". Твоя реакция будет в исправлении под каждый попавшийся протектор или в совете нормально настроить сервак(для PHP, а не для связки PHP + VasyaPupkin's Protector)?

Если он не меняет механики работы - то не кривой.
Сухосин же меняет именно механику работы PHP. Значит он зло.

Я знаю. Но меня не предупредили насчет левых(а он неофициальный(т.е. левый) патч, не на php.net лежит). Если бы предупредили, то я бы ~30% к цене накинул бы за дополнительную отладку на сервере в случае НЁХ(неведомой ебаной ***ни). Пусть платят за безопасность.

Я не поддерживаю свой софт, если это не оговорено.
А завтра VovaMorkovkin's Path выйдет, мой скрипт и его поддерживать должен и еще всякую левость?
Я более доверяю команде PHP, чем какому-то чуваку, который делает порт во фряхе.

В моей практике имеется ТЗ в котором достаточно жестко прописаны требования к хостинговой площадке (без которых или с которыми точно работать будет/не будет), есть _рекоммендуемая_ хостинговая площадка. Обязательно оговорка о дополнительной оплате в случае неработоспособности на хостингововй площадке заказчика (естественно сумма оплаты определится дополнительным договором), это если заказчика вдруг перестала устраивать рекоммендуемая площадка (он ведь знал о ней когда подписывал).
Ведь на самом деле, даже устанавливая PHP с различными SAPI (CGI, CLI и проч.) ты уже влияешь на переменные окружения выполняемого скрипта. Старый прикол, $_SERVER['SCRIPT_NAME'] возвратит php.cgi вместо имени скрипта при использовании PHP-CGI SAPI (имел место в 5.1.5 вроде, не знаю как сейчас, лень проверять ;) Так что, хоть и скачано с php.net, а приколы остались. Так что в этом плане ты ССЗБ, что не подумал об этом сам заранее). Я молчу про стандартные фичи типа Safe Mode, MagicQutes и ещё нескольких менее очевидных и менее известных режимов/опций/настроек в php.ini при которых твоё приложение не будет работать корректно. Ну и само собой, гарантийные обязательства по обновлению и поддержке также оформляются отдельно.

Очень показательной по теме Suhosin/Hardened Patch является статья Роковые ошибки PHP, смотрим вывод (из серии семь бед - один ответ). Ты может быть и думаешь что у тебя такое правильное идеальное приложение (как и сотни/тысячи/миллионы других разроботчиков чьи продукты красиво светятся в лентах багтрэков), но таких не бывает в реальных проектах. Программа обязательно ведёт себя не так как ты думаешь в самом неожиданном месте, но при этом она может оставаться полностью функциональной, просто об этом никто не подозревает, потому что это скрыто от глаз, это внутрення работа интерпретатора. Особенно актуально для PHP с его гибкостью во всём (чего стоит одно прозрачное определения типов данных и их динамическое приведение). Всё о чём там говорится не актуально при установленном Suhosin, который уже давно не является поделкой. Поддерживается он не только в портах FreeBSD. Ubuntu/Debian - есть и тоже ставится по умолчанию. Не хочу сейчас все дистрибутивы перебирать, такой сабж нашел: Wordpress and many other open source application developers asks users to protect PHP apps using Suhosin patch to get protection from the full exploit (http://www.cyberciti.biz/faq/rhel-linux-install-suhosin-php-protection/). Так что, имхо, пользы больше.

Пожалуй, больше мне добавить нечего.