On Mon, Nov 20, 2023 at 03:25:54PM +0300, Alexey Shabalin wrote: > пн, 20 нояб. 2023 г. в 12:20, Anton Farygin : > > 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 и т.п.