From: Anton Farygin <rider@basealt.ru> To: devel@lists.altlinux.org Subject: Re: [devel] UserGroupPolicy ? Date: Mon, 20 Nov 2023 12:20:13 +0300 Message-ID: <b7757be0-ae23-4639-9c5c-979c8efe03e3@basealt.ru> (raw) In-Reply-To: <ZVsdipYo36Jd8jmK@cello> 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 очень консервативные ментейнеры. >> >> Было бы неплохо придумать какую-то схему по выделению/резервированию UID/GID >> для системных служб. > Я не уверен, что это реально нужно и стоит делать в репозитории. > Наверное, будет удобно и достаточно стащить у системдоидов программу > sysusers[1], превратив её в самостоятельную. > > Далее — завести пакет static-ugids-setup, где вести реестр таких уидов в > виде отдельных файликов-записей. Внутри одного пакета будет легче > следить за непересечениями, чем между разными пакетами. Пакет без явного > мейнтейнера (@everybody), но с проверкой. > Но тогда непонятно, из какого диапазона можно безопасно выделять уиды > так, чтобы они не были заняты в существующих системах, и хватит ли этих > уидов всем таким капризным службам в репозитории. > Директива DynamicUser= в systemd себе прихватила некоторый отрезок после > [UG]ID_MAX-настройки в /etc/login.defs. > > [1] man 5 sysusers.d Да, вопросов возникает тоже много. Ответы на них надо прорабатывать, а sysusers выглядит интересной идеей для реализации политики управления системными пользователями. Контроль за соблюдением в пакетах можно переложить на sisyphus_check, например.
next prev parent reply other threads:[~2023-11-20 9:20 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-15 13:00 [devel] NobodySubjectPolicy draft Arseny Maslennikov 2023-11-15 13:42 ` Sergey V Turchin 2023-11-15 17:47 ` Arseny Maslennikov 2023-11-15 17:52 ` Arseny Maslennikov 2023-11-16 5:39 ` [devel] UserGroupPolicy ? Anton Farygin 2023-11-20 8:49 ` Arseny Maslennikov 2023-11-20 9:20 ` Anton Farygin [this message] 2023-11-20 12:25 ` Alexey Shabalin 2023-11-20 14:15 ` [devel] UID/GID pinning for packaged services Arseny Maslennikov 2023-11-20 14:36 ` Denis Medvedev 2023-11-20 15:48 ` Dmitry V. Levin 2023-11-16 6:55 ` [devel] NobodySubjectPolicy draft Sergey V Turchin 2023-11-16 7:57 ` Anton Farygin 2023-11-16 8:03 ` Sergey V Turchin 2023-11-16 8:33 ` Anton Farygin 2023-11-16 8:41 ` Sergey V Turchin 2023-11-16 8:52 ` Anton Farygin 2023-11-16 8:58 ` Sergey V Turchin 2023-11-16 7:02 ` Sergey V Turchin 2023-11-20 8:23 ` Sergey V Turchin 2023-11-20 8:41 ` Arseny Maslennikov 2023-11-20 11:22 ` Arseny Maslennikov 2023-11-22 11:56 ` Arseny Maslennikov 2023-12-19 17:51 ` Arseny Maslennikov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b7757be0-ae23-4639-9c5c-979c8efe03e3@basealt.ru \ --to=rider@basealt.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git