Re: [devel] UserGroupPolicy ?

[Alexey Shabalin <a.shabalin@gmail.com>]

пн, 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:
> >> On 15.11.2023 20:52, Arseny Maslennikov wrote:
> >>> On Wed, Nov 15, 2023 at 08:48:00PM +0300, Arseny Maslennikov wrote:
> >>>> часть её протокола взаимодействия с кем-то, то лучше завести отдельную,
> >>>> _kdesu какое-нибудь.
> >>> У нас же правило о том, что имена системных усеров и групп, добавляемых
> >>> пакетами, должны начинаться с _, утверждено как обязательное, надеюсь?
> >>>
> >>> Так себе и представляю живого пользователя-анимешника с никнеймом K-desu. :]
> >> Не видел такого правила.
> >>
> >> Это, кстати, было бы отлично привести в порядок.
> > И заодно разобраться с подразумеваемым смыслом всяких волшебных групп вроде wheel.
> > Ничего, впрочем, не мешает сначала утвердить nobody, а далее, если появится
> > пропозал, включить содержимое NobodySubjectPolicy целиком или частично туда.
> Да, против Nobody ничего не имею.
> >
> >> Есть ещё одна проблема - иногда так случается, что системные сервисы на
> >> разных узлах должны работать под одним UID/GID
> > Это чтобы потакать криворукому софту, или ради общих R/W ФС на кластер?
>
> Общие R/W ФС на кластер, сохранение/восстановление из бэкапа,
> копирование данных из одного сервера в другой через rsync.
>
> Сценариев точно больше одного. Кривой софт тоже встречается, но гораздо
> реже.
>
>
> >
> >> Сейчас у нас нет внятного механизма заведения таких системных пользователей.
> >>
> >> А у пакета setup очень консервативные ментейнеры.

На самом деле, консервативный мантейнер (ldv@) согласился со мной, что
бывают ситуации, где необходим статический UID/GUI. Или сделал вид что
согласился :)
Если будет предложен нормальный вариант, я думаю они будут не против.

> >>
> >> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID
> >> для системных служб.
> > Я не уверен, что это реально нужно и стоит делать в репозитории.

Можно быть сколько угодно уверенным или нет. Такая необходимость
просто существует.
Еще раз, не всем и не везде это нужно, но это нужно.
И уже сейчас в репо есть пакеты, где 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 и т.п.

-- 
Alexey Shabalin