[devel] UID/GID pinning for packaged services

[Denis Medvedev]

On Mon, 20 Nov 2023 17:15:21 +0300
Arseny Maslennikov <arseny на altlinux.org> wrote:

> On Mon, Nov 20, 2023 at 03:25:54PM +0300, Alexey Shabalin wrote:
> > пн, 20 нояб. 2023 г. в 12:20, Anton Farygin <rider на basealt.ru>:
> > > On 20.11.2023 11:49, Arseny Maslennikov wrote:
> > > > On Thu, Nov 16, 2023 at 08:39:13AM +0300, Anton Farygin wrote:
> > > >> Есть ещё одна проблема - иногда так случается, что системные
> > > >> сервисы на разных узлах должны работать под одним UID/GID
> > > > Это чтобы потакать криворукому софту, или ради общих R/W ФС на
> > > > кластер?
> > >
> > > Общие R/W ФС на кластер, сохранение/восстановление из бэкапа,
> > > копирование данных из одного сервера в другой через rsync.
> > >
> > > Сценариев точно больше одного. Кривой софт тоже встречается, но
> > > гораздо реже.
> 
> Все описанные сценарии затрагивают конкретные деплойменты (на местах у
> людей), которые никак не касаются мн-ва остальных пользователей.
> 
> А ещё все описанные сценарии касаются общих ресурсов, где хранятся эти
> uid/gid в качестве метаданных, но тут не буду настаивать.
> 
> Иными словами, всё ещё не требуется синхронизировать все инсталляции
> альта в мире, фиксировать эти числа в _глобальном_ реестре. Можно
> искать решение для конкретных инсталляций: администратор на этапе
> установки доводит до установщика пожелание: "разверните мне систему и
> пакеты так, чтобы уид/гид у сервиса X был ровно N". Т. е. поддержка в
> альтератор-headless (или как у нас неинтерактивный инсталлятор
> называется?), может быть, даже в GUI инсталлятора.
> 
> > > >
> > > >> Сейчас у нас нет внятного механизма заведения таких системных
> > > >> пользователей.
> > > >>
> > > >> А у пакета setup очень консервативные ментейнеры.
> > 
> > На самом деле, консервативный мантейнер (ldv@) согласился со мной,
> > что бывают ситуации, где необходим статический UID/GUI. Или сделал
> > вид что
> 
> Бывают. Все они, скорее всего, сводятся к тому, что uid/gid
> используется до того, как появляется доступ к nsswitch, а то и
> раньше, чем появляется /etc (то есть, в initramfs), и компоненты, ими
> пользующиеся, начинают это делать на столь раннем этапе работы
> (старта) системы. А если не все — буду рад увидеть контрпримеры.
в pam можно указывать только числовые значения для = или >=
В частности, для selinux приходилось резервировать числовое значение
"90" для выделенного администратора которого надо было прописывать в
pam.
>  
> > > >> Было бы неплохо придумать какую-то схему по
> > > >> выделению/резервированию UID/GID для системных служб.
> > > > Я не уверен, что это реально нужно и стоит делать в репозитории.
> 
> Ключевыми у меня здесь являются слова "в репозитории". :)
> Я не возражаю против поддержки гвоздями прибитых ugid как таковой,
> просто решение о том, какое должно быть число, совсем не обязательно
> принимать рано, в репозитории; его можно отложить, например, до работы
> установщика.
> Я не уверен, что реестр должен быть общим для всех установок альта в
> в мире.
> 
> > Можно быть сколько угодно уверенным или нет. Такая необходимость
> > просто существует.
> > Еще раз, не всем и не везде это нужно, но это нужно.
> > И уже сейчас в репо есть пакеты, где useradd/groupadd вызываются с
> > указанием UID/GUID.
> > Нужно легитимизировать такую практику и придумать правила.
> > 
> > > > Наверное, будет удобно и достаточно стащить у системдоидов
> > > > программу sysusers[1], превратив её в самостоятельную.
> > > >
> > > > Далее — завести пакет static-ugids-setup, где вести реестр
> > > > таких уидов в виде отдельных файликов-записей. Внутри одного
> > > > пакета будет легче следить за непересечениями, чем между
> > > > разными пакетами. Пакет без явного мейнтейнера (@everybody), но
> > > > с проверкой. Но тогда непонятно, из какого диапазона можно
> > > > безопасно выделять уиды так, чтобы они не были заняты в
> > > > существующих системах, и хватит ли этих уидов всем таким
> > > > капризным службам в репозитории. Директива DynamicUser= в
> > > > systemd себе прихватила некоторый отрезок после
> > > > [UG]ID_MAX-настройки в /etc/login.defs.
> > 
> > 61184…65519 - UIDs for dynamic users
> > Они не подпадают под категорию статических системных пользователей.
> > Давайте не будем их тут рассматривать.
> > 
> > Сейчас у нас системные пользователи до 1000, раньше были до 500.
> > useradd/groupadd начинает выдавать системным пользователям uid/gui с
> > конца в сторону уменьшения (сейчас с 999, раньше с 499).
> > Можно предположить, что на старых системах диапазон от 400-499
> > занят и 500-599 тоже, на новых 900-999 занят.
> > Думаю, для статических uid/gui диапазон 100-400 или 600-900
> > относительно безопасен. Конечно не на все 100%.
> > 
> > 
> > > >
> > > > [1] man 5 sysusers.d
> > >
> > > Да, вопросов возникает тоже много. Ответы на них надо
> > > прорабатывать, а sysusers выглядит интересной идеей для
> > > реализации политики управления системными пользователями.
> > >
> > > Контроль за соблюдением в пакетах можно переложить на
> > > sisyphus_check, например.
> > 
> > Давайте прикинем варианты учета и правила создания таких
> > статических UID/GID.
> > - страничка на wiki с таблицей статических UID/GID. Этот вариант
> > можно сразу отвергнуть. Единоразово страницу сделать можно, но
> > потом без автоматического обновления она быстро перестанет быть
> > актуально.
> > - пакет static-ugids-setup. пользователю приедет куча ненужных
> > системных пользователей и групп, еще и с домашними директориями.
> > - у меня еще была идея провайдить в rpm что-то типа sysusers(uid) =
> > 300 и sysusers(gid) = 300 для системных пользователей, создаваемых в
> > %pre. Тогда сборочница сама отследит одинаковые провайды и не
> > пропустит пакет.
> > - у нас нет макросов для useradd и groupadd, сейчас что только не
> > пишут в %pre. Для унификации создания системных пользователей стоит
> > задействовать sysusers (отработает и в systemd, и в sysv). Если в
> > этих файлах прописан статический UID/GID то можно автоматически
> > выставлять Provides: sysusers(uid) = $UID и т.п.