Поддержка сторонних пакетов rpm в ОС Альт (OSSDEVCONF-2018)
Материал из 0x1.tv
- Докладчик
Традиционно дистрибутивы операционных систем семейства Альт рассматриваются разработчиками в первую очередь как реализация программной платформы для совместных программных и программно-аппаратных решений. При этом сами разработчики ОС рекомендуют технологическим партнёрам оформлять свои программные продукты в виде пакетов rpm, собранных в соответствии с правилами, принятыми для пакетов ОС Альт, и с помощью нативных инструментов ОС Альт.
К сожалению, не все разработчики с готовностью внедряют соответствующие технологии и соблюдают правила. Иногда в совместных проектах встречаются пакеты, разрушительно влияющие на другие компоненты и систему в целом. Авторы доклада предлагают краткий обзор возможных подходов к решению этой проблемы.
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Thesis
Основной источник проблемы — умолчальное разрешение на использование произвольных сценариев в пакетах. База данных rpm позволяет отслеживать конфликты между пакетами на уровне файлов. Но, если с точки зрения разработчика стороннего по отношению к системе пакета какой-то файл, предоставленный другим пакетом, просто необходимо заменить — это легко можно сделать на уровне сценариев, входящих в состав пакета и автоматически выполняющихся при его установке. Конфликта при установке пакета не возникнет. При проверке соответствия дерева каталогов записям в базе данных rpm конфликт будет замечен, конечно же, но тогда будет уже поздно — пакет установлен и «всё работает». При этом для такого разработчика не вполне очевидно, что «работает» только его часть, а остальные компоненты совместного решения вполне могут пострадать.
К обсуждению предлагается три возможных подхода к решению проблемы: запретить выполнение сценариев при установке и удалении пакета, разрешить выполнение сценариев только для доверенных пакетов, отслеживать файловые операции в сценариях и считать их такими же модификациями дерева каталогов, как и установку файлов из пакета.
Полный запрет выполнения сценариев в пакетах с точки зрения обеспечения целостности системы выглядит многообещающе. Но для реализации этой идеи потребуется как-то формализовать и автоматизировать рутинные операции, для которых установочные сценарии сейчас используются ответственными разработчиками. В этом смысле понятно, что можно сделать, например, с добавлением пользователей и групп — добавить их в виде объектов в базу данных rpm. При этом появится дополнительное преимущество в виде возможности устанавливать соответствующие зависимости. С запуском и остановом служб, предоставляемых пакетом, направления поиска решения тоже понятны — можно попробовать так же интегрировать в базу данных rpm unit-ы системы инициализации systemd. Возможно, трудоёмкость этой задачи окупится преимуществами отказа от выполнения произвольных сценариев и новыми типами зависимостей. Но что делать, например, со сценариями миграции — вопрос более сложный. Действительно, существует ряд плохо формализуемых задач, решение которых в случае отказа от выполнения сценариев потребует отдельной исследовательской работы.
Ещё один важный аспект запрета сценариев — реакция сообщества коммерческих компаний-разработчиков на такое изменение. Здесь важно иметь в виду не столько психологические моменты, связанные с новыми запретами, сколько неожиданные трудозатраты, необходимость которых может быть не очевидной. Поэтому, возможно, имеет смысл одновременно предлагать разработчикам новые для них технологии, позволяющие оптимизировать сборку и упаковку ПО для различных отечественных ОС. Здесь перспективными выглядят технологии, разработанные и успешно применяемые в компании Этерсофт — в частности, Коринф и epm, уже неоднократно обсуждавшиеся на этой конференции. Таким образом, перейдя на единый сборочный сценарий, разработчики смогут сэкономить ресурсы и одновременно сделать свои пакеты более пригодными для использования в составе совместных решений.
Второй из предлагаемых подходов к решению проблемы сценариев — разрешение на их выполнение только при установке доверенных пакетов. Например, подписанных участниками Alt Linux Team. Этот вариант хорош тем, что может стимулировать коммерческих разработчиков вствпать в Team и сопровождать там пакеты типа -preinstall, которые сейчас широко используются в качестве прослойки между дистрибутивными и недистрибутивными пакетами, предоставляя недостающие зависимости. Как свойственно полумерам, это «решение» по сути не решает проблему выполнения произвольных сценариев, а просто переносит её в другую плоскость. Очевидно, введение такого решения в качестве единственного может вызвать очередное «соревнование снаряда и брони» в виде расширения списка разрешений на уровне конкретных внедрений.
Третий подход, предлагаемый авторами к рассмотрению — интегрировать в rpm технологию, позволяющую полностью отслеживать изменения дерева каталогов, происходящие в процессе установки пакета, и трактовать их одинаково вне зависимости от того, чем они были вызваны — установкой файлов или работой сценариев. В качестве возможных направлений реализации можно рассмотреть файловые системы на базе оверлеев. Очевидно, что дополнительная проверка вызовет рост накладных расходов, но проблема выполнения произвольного кода с максимальными привилегиями настолько существенна, что, предположительно, эти расходы могут окупиться.
Авторы не предлагают при рассмотрении проблемы ограничиваться каким-то одним из предложенных подходов к решению. Возможно, имеет смысл применять их частично и комплексно. Также, выступление является приглашением к обсуждению проблемы как на конференции, так и за её рамками.
!.jpg)
Примечания и ссылки
- В дискуссии упоминается доклад Flock 2017 - Scriptlet Reform and RPM Independence: building images in the Container Era
Plays:45 Comments:1