Pull to refresh

Comments 27

Если php.ini был скопирован из пятой версии
При чём тут Ubuntu Xenial, если вы скопировали этот файл вручную?
На убунте пхп 7 имеет отдельные папки для конфигов и она создаёт там новые конфиги при установке.
Именно тот случай, где сделали — то, чего нельзя было делать и изобрели к нему костыли. К тому же у xenial по умолчанию стоят ppa не от ondrej/php.
К тому же у xenial по умолчанию стоят ppa не от ondrej/php.

Проблема воспроизводится и в официальных пакетых от убунты, и в пакетах из ondrej/php.

При чём тут Ubuntu Xenial, если вы скопировали этот файл вручную?

У нас этот файл раскладывается ролью ansible, и при переделывании роли с php5 на php7 я его просто скопировал и проверил по документации, что все используемые директивы работают так же. Вне зависимости от используемого метода поставки настроек(ansible, puppet, dockerfile, AWS AMI, ...) — при обновлении проще скопировать старый файл, чем в новом вручную прописывать те же настройки. Даже если переписывать файл с нуля — кто-то по привычке поставит # для комментария, и всё молча поломается.

Обратная совместимость? Нет, не знаем.
UFO just landed and posted this here
Обратная совместимость не должна зависеть от версий совсем, особенно в enterprise языках, как сейчас позиционирует себя PHP.
Мажорная версия имеет право сбрасывать костыли, иначе такой full of legacy никому будет не нужен в будующем.
Не имеет права. Иначе получается ужасная ситуация, когда есть тонны старого работающего кода, но обновлять версию нельзя из-за проблем совместимости, но и продолжать использовать старые версии тоже нельзя из-за прекращения поддержки и дыр в безопасности.
С такой логикой новые deprecated функции тоже не имеют право на существование, ведь из-за их наличия нельзя обновится, а старую версию нельзя использовать из-за дыр.

Проблема возникает только в том случае, когда конфиг файл накатили от несовместимой версии. Ну так не накатывайте, перенести настройки или проверьте его на совместимость. Вот и всё решение.
О том, что # — deprecated, предупреждало в startup errors года 3-4.

Вас послушать — так и register globals с magic quotes надо вечно тянуть было.

>обновлять версию нельзя из-за проблем совместимости
sed -i 's/^#/;/' php.ini
Ужасная проблема совместимости. Исправить уйдут человекогоды.
Это ж каким ССЗБ надо быть, чтобы обновить мажорную версию прямо на продакшене без тестирования.

Так в том и весь прикол, что при тестировании всё работает, только со значениями по-умолчанию. Если не используются загрузки больших файлов и другие явно ломающиеся вещи, то деградацию можно не заметить: странички открываются, все функции приложения работают, 500 не выпадает. А то, что оно начало отдавать X-Powered-By:, больше не органичивает доступные PHP функции и на ошибки отдаёт пользователю стектрейс — с первого взгляда не видно.

У вас тестирование сводится к «странички открываются»? Acceptance-тесты, CI — не?

>больше не органичивает доступные PHP функции
а это вообще зачем, кроме шаред-хостинга?
Удивительно видеть в одном сообщении претензию к отсутствию полноценного тестирования и удивление по поводу ограничивания функций.

Вы наверное на сервере из под рута все время работаете? Исходя из логики «а зачем не из под рута, ведь доступ только у меня»:)

Дыры могут быть в любом сайте, отключение некоторых функций пхп это банально безопаснее, т.к. по крайней мере Вы можете быть уверены, что даже если Ваш пхп сайт ломанут, то хотя бы в консоли не смогут чего-нибудь выполнить через пхп.
Достаточно нормально настроить ограничения средствами операционной системы. Это и понадежнее будет.
Сознательно отказаться от дополнительного слоя безопасности? Ради чего?
Или Вы не в курсе что ОС тоже имеют уязвимости?
Trust noone:)

Вот, кстати, ничего так пример обхода ограничений https://habrahabr.ru/company/pentestit/blog/227497/
Отключение функций — это иллюзия безопасности, в том и дело.
Если совмещать, это другой вопрос.
Возможно Вам стоит почитать больше про отключение функций.
Отключение функций это повышение безопасности, а не иллюзия, т.к. доступ из консоли имеет больше возможностей и прав, чем доступ непосредственно их пхп.
А ограничение доступа это всегда хорошо, даже если не совмещать.
Да и пассаж про совмещать странный, для Вас не самоочевидно что подходы к ограничению надо совмещать?
У вас тестирование сводится к «странички открываются»? Acceptance-тесты, CI — не?

Оно прошло тестирование, подробности — NDA. Разумеется, теперь мы добавили дополнительные проверки.


а это вообще зачем, кроме шаред-хостинга?

Немного уменьшаем поверхность атаки на случай уязвимостей в коде. Не факт что сильно поможет, но и не помешает

Вообще это похоже на проблему php-fpm, это же он стартует с неправильным конфигом?
Лучше им напишите репорт.
Не «сервера», а «серверы» будет по-русски.

https://ru.wiktionary.org/wiki/сервер:


В разговорной речи встречается также вариант склонения по схеме 1c(1) (мн. ч. сервера́, серверо́в, сервера́м, сервера́ми, сервера́х).

На мой вкус сервера звучит приятнее, но ваш вариант более академически привильный.

Во-первых, здесь не разговорная речь. Во-вторых, в разговорной речи, например, говорят «ихний» и «кушайте», что автоматически не делает эти слова часть> грамотного изъяснения на русском. И, наконец, в-третьих — вы, конечно, вольны делать что хотите, но окружающие будут судить о вашем образовании и интеллекте, в первую очередь, по степени владения языком.
Здесь как раз разговорная речь, а не литературная.
по степени владения языком


надеюсь вы про PHP ;)
Sign up to leave a comment.

Articles