[devel] UID/GID pinning for packaged services

[Arseny Maslennikov]

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), и компоненты, ими пользующиеся, начинают
это делать на столь раннем этапе работы (старта) системы.
А если не все — буду рад увидеть контрпримеры.
 
> > >> Было бы неплохо придумать какую-то схему по выделению/резервированию 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 и т.п.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20231120/005c57d2/attachment-0001.bin>