[devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

Hi!

В опубликованный сегодня Sisyphus вошёл новый rpm-build:
> rpm-build - Scripts and executable programs used to build packages
> * Thu Jan 11 2024 Arseny Maslennikov <arseny@altlinux> 4.0.4.195-alt1
> - debuginfo: Changed compression format (--lzma2=dict=2MiB ->
>   --check=crc32 --lzma2=dict=1MiB) of xz-compressed modules for compatibility
>   with kmod >= 31 (thx asheplyakov@).
> - Introduced brp-verify-unit to check sanity of systemd units included
>   in built packages.

Новый brp-модуль проверяет юниты systemd на вшивость. Пока он содержит
две проверки:
* <...>
* файл с systemd-юнитом, предусматривающим порождение процесса, не
  должен запускать что-либо под nobody.

В результате сегодняшней тестовой пересборки обнаружилось[1] 5 пакетов,
содержащих systemd-юниты, предписывающие запускать что-либо под nobody.

[1] https://lore.altlinux.org/sisyphus-cybertalk/Zcb1ezIHJkgVff21@beehive.mskdc.altlinux.org/T/#u

Пакеты, перечисленные ниже, нужно исправить, убрав из директив User= и
Group= упоминания uid и gid 65534 и имени nobody.
Лучше всего завести им отдельного пользователя (и, в случае
mariadb-server-galera, группу). systemd поддерживает директиву
DynamicUser=, но я не видел её применения на практике в классических
дистрибутивах, кроме, может быть, юнитов к программам из состава проекта
systemd.

Под каждой цитатой из лога пересборки указан acl на пакет.

bozohttpd-20220517-alt1
	044-verify-unit.brp: bad permissions on "/lib/systemd/system/bozohttpd@.service":
	-rwxr-xr-x
	044-verify-unit.brp: ERROR: "/lib/systemd/system/bozohttpd@.service" assumes overflowugid
	credentials
bozohttpd	george @everybody

gnunet-0.11.5-alt2
	Verifying systemd units in /usr/src/tmp/gnunet-buildroot
	044-verify-unit.brp: ERROR: "/lib/systemd/system/gnunetd.service" assumes overflowugid
	credentials
gnunet	lav viy @everybody

lizardfs-3.13.0-alt0.rc4.1
	Verifying systemd units in /usr/src/tmp/lizardfs-buildroot
	044-verify-unit.brp: ERROR: "/lib/systemd/system/lizardfs-cgiserv.service" assumes
	overflowugid credentials
lizardfs	andy @everybody

mariadb-10.11.6-alt1
	Verifying systemd units in /usr/src/tmp/mariadb-buildroot
	044-verify-unit.brp: ERROR: "/lib/systemd/system/mariadbcheck@.service" assumes
	overflowugid credentials
mariadb	shaba @everybody

xfsprogs-6.3.0-alt1
	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
	044-verify-unit.brp: ERROR: "/lib/systemd/system/xfs_scrub@.service" assumes overflowugid
	credentials
xfsprogs	rider mike @qa

См. также: https://altlinux.org/NobodySubjectPolicy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Anton Farygin]

On 10.02.2024 14:37, Arseny Maslennikov wrote:
> xfsprogs-6.3.0-alt1
> 	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
> 	044-verify-unit.brp: ERROR:"/lib/systemd/system/xfs_scrub@.service"  assumes overflowugid
> 	credentials
> xfsprogs	rider mike @qa

Что-то я не пойму, какое решение предлагается в данном случае и чем так 
плох nobody для той операции, которую выполняет данный unit ?

nobody выбран апстримом.

Запуск данного юнита под nobody - общепринятая практика во всех 
дистрибутивах Linux, исключения мне не известны.

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

On Sat, Feb 10, 2024 at 05:06:13PM +0300, Anton Farygin wrote:
> On 10.02.2024 14:37, Arseny Maslennikov wrote:
> > xfsprogs-6.3.0-alt1
> > 	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
> > 	044-verify-unit.brp: ERROR:"/lib/systemd/system/xfs_scrub@.service"  assumes overflowugid
> > 	credentials
> > xfsprogs	rider mike @qa
> 
> чем так плох nobody для той операции, которую выполняет данный unit ?

nobody у нас скоро превратится в overflowuid, под которым ничего не
должно работать.

Более того, никто не будет гарантировать на каждой инсталляции, что под
этим nobody или _nobody99 работает только xfs_scrub.

> nobody выбран апстримом.

Это тот ныне нечастый случай, где тем хуже для апстрима.

Более того, судя по коммиту 824b5807fb1e1a0e156b183a591f23b096c8868f, в
котором юнит появился и после которого фундаментально менялся только
один раз (PrivateTmp= выключили), апстрим об этом особо не думал, ибо
никто ему об этом соображении не рассказал.

> Запуск данного юнита под nobody - общепринятая практика во всех
> дистрибутивах Linux, исключения мне не известны.

Как я понимаю, Альт его сообщество любит в первую очередь за
непопулярные технические решения. А здесь как раз повод принять такое
решение, в котором есть смысл! :D

> Что-то я не пойму, какое решение предлагается в данном случае

Лучше всего завести для него отдельного пользователя (или, может, для
всех xfsprogs).

Если это по какой-то причине невозможно, есть другие варианты:
* использовать _nobody99, которого мы добавим в задании 330460;
  (systemd позволяет даже число в качестве User= указать :))
* если учесть, что много что в юните закрыли, какого-нибудь daemon из
  головы /etc/passwd;
* повторюсь: лучше всего для таких случаев (программа без хранилища)
  подходит DynamicUser=yes, но на практике я его не видел, и в этом
  случае автоматически зафиксируется PrivateTmp=yes, т. е. поскрабать
  таким юнитом ФС, примонтированную под /tmp, не получится.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Dmitry V. Levin]

On Sat, Feb 10, 2024 at 06:23:02PM +0300, Arseny Maslennikov wrote:
> On Sat, Feb 10, 2024 at 05:06:13PM +0300, Anton Farygin wrote:
> > On 10.02.2024 14:37, Arseny Maslennikov wrote:
> > > xfsprogs-6.3.0-alt1
> > > 	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
> > > 	044-verify-unit.brp: ERROR:"/lib/systemd/system/xfs_scrub@.service"  assumes overflowugid
> > > 	credentials
> > > xfsprogs	rider mike @qa
> > 
> > чем так плох nobody для той операции, которую выполняет данный unit ?
> 
> nobody у нас скоро превратится в overflowuid, под которым ничего не
> должно работать.
[...]
> > Запуск данного юнита под nobody - общепринятая практика во всех
> > дистрибутивах Linux, исключения мне не известны.
> 
> Как я понимаю, Альт его сообщество любит в первую очередь за
> непопулярные технические решения. А здесь как раз повод принять такое
> решение, в котором есть смысл! :D

Кто-нибудь может мне рассказать, почему ядро до сих пор ещё разрешает
setuid(overflowuid)?  Это же по сути отменяет саму идею, заложенную
в overflowuid.


-- 
ldv

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Anton Farygin]

On 10.02.2024 18:23, Arseny Maslennikov wrote:
> On Sat, Feb 10, 2024 at 05:06:13PM +0300, Anton Farygin wrote:
>> On 10.02.2024 14:37, Arseny Maslennikov wrote:
>>> xfsprogs-6.3.0-alt1
>>> 	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
>>> 	044-verify-unit.brp: ERROR:"/lib/systemd/system/xfs_scrub@.service"  assumes overflowugid
>>> 	credentials
>>> xfsprogs	rider mike @qa
>> чем так плох nobody для той операции, которую выполняет данный unit ?
> nobody у нас скоро превратится в overflowuid, под которым ничего не
> должно работать.
Почему-то при этом в других дистрибутивах работает. Или overflow uid 
сделаем только мы ?
>
> Более того, никто не будет гарантировать на каждой инсталляции, что под
> этим nobody или _nobody99 работает только xfs_scrub.
>
>> nobody выбран апстримом.
> Это тот ныне нечастый случай, где тем хуже для апстрима.
>
> Более того, судя по коммиту 824b5807fb1e1a0e156b183a591f23b096c8868f, в
> котором юнит появился и после которого фундаментально менялся только
> один раз (PrivateTmp= выключили), апстрим об этом особо не думал, ибо
> никто ему об этом соображении не рассказал.

А можете донести эту мысль до апстрима ?

>
>> Запуск данного юнита под nobody - общепринятая практика во всех
>> дистрибутивах Linux, исключения мне не известны.
> Как я понимаю, Альт его сообщество любит в первую очередь за
> непопулярные технические решения. А здесь как раз повод принять такое
> решение, в котором есть смысл! :D
Мне непонятно какое именно техническое решение повод принять.
>
>> Что-то я не пойму, какое решение предлагается в данном случае
> Лучше всего завести для него отдельного пользователя (или, может, для
> всех xfsprogs).

Возможно, но мне хотелось бы что бы заведение системного пользователя 
было осмысленно.

Возможно нам нужен пользователь не для xfs_scrub, а в целом для операций 
над FS ?

>
> Если это по какой-то причине невозможно, есть другие варианты:
> * использовать _nobody99, которого мы добавим в задании 330460;
>    (systemd позволяет даже число в качестве User= указать :))
Это же костыль. Зачем он нужен ?
> * если учесть, что много что в юните закрыли, какого-нибудь daemon из
>    головы /etc/passwd;
Неизвестно, кто захочет и как использовать данный UID. Да и демон - это 
не то, чем можно назвать xfs_scrub
> * повторюсь: лучше всего для таких случаев (программа без хранилища)
>    подходит DynamicUser=yes, но на практике я его не видел, и в этом
>    случае автоматически зафиксируется PrivateTmp=yes, т. е. поскрабать
>    таким юнитом ФС, примонтированную под /tmp, не получится.
Верно, тоже не решение.

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Anton Farygin]

On 12.02.2024 01:12, Dmitry V. Levin wrote:
> Кто-нибудь может мне рассказать, почему ядро до сих пор ещё разрешает
> setuid(overflowuid)?  Это же по сути отменяет саму идею, заложенную
> в overflowuid.
>
>
Сейчас при входе в систему доменным пользователем UID получается 32-х 
битный.

overflow оно только на старых системах, где UID/GID 16-бит.

Re: [devel] I: brp-verify-unit: "... assumes overflowugid

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-02-12 08:44:19 +0300, Anton Farygin wrote:

 >>> Что-то я не пойму, какое решение предлагается в данном случае
 >> Лучше всего завести для него отдельного пользователя (или,
 >> может, для всех xfsprogs).
 > Возможно, но мне хотелось бы что бы заведение системного
 > пользователя было осмысленно.
 > Возможно нам нужен пользователь не для xfs_scrub, а в целом
 > для операций над FS ?

Да. Вот такой:

disk:5:5:Block device manager:/var/empty:/bin/false


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: brp-verify-unit: "... assumes overflowugid

[Anton Farygin]

On 12.02.2024 10:45, Alexey V. Vissarionov wrote:
> Good ${greeting_time}!
>
> On 2024-02-12 08:44:19 +0300, Anton Farygin wrote:
>
>   >>> Что-то я не пойму, какое решение предлагается в данном случае
>   >> Лучше всего завести для него отдельного пользователя (или,
>   >> может, для всех xfsprogs).
>   > Возможно, но мне хотелось бы что бы заведение системного
>   > пользователя было осмысленно.
>   > Возможно нам нужен пользователь не для xfs_scrub, а в целом
>   > для операций над FS ?
>
> Да. Вот такой:
>
> disk:5:5:Block device manager:/var/empty:/bin/false
>
>
disk имеет rw привелегии на устройства, это перебор.

Re: [devel] I: brp-verify-unit: "... assumes overflowugid

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-02-12 10:52:36 +0300, Anton Farygin wrote:

 >>>> Лучше всего завести для него отдельного пользователя (или,
 >>>> может, для всех xfsprogs).
 >>> Возможно, но мне хотелось бы что бы заведение системного
 >>> пользователя было осмысленно.
 >>> Возможно нам нужен пользователь не для xfs_scrub, а в целом
 >>> для операций над FS ?
 >> Да. Вот такой:
 >> disk:5:5:Block device manager:/var/empty:/bin/false
 > disk имеет rw привелегии

Все же "привИлегии". Или, еще лучше, по-русски: "права".

 > на устройства, это перебор.

Эт хде? В системах с udev? Значит, там и надо исправлять.

В системах без этого руткита ядро с CONFIG_DEVTMPFS_MOUNT создает
блочные устройства 0600:

% ll /dev/sd*
brw------- 1 root root 8,  0 сен  6 08:33 /dev/sda
brw------- 1 root root 8,  1 сен  6 08:33 /dev/sda1
brw------- 1 root root 8,  2 сен  6 08:33 /dev/sda2
brw------- 1 root root 8, 16 сен  6 08:33 /dev/sdb
brw------- 1 root root 8, 17 сен  6 08:33 /dev/sdb1
brw------- 1 root root 8, 18 сен  6 08:33 /dev/sdb2
brw------- 1 root root 8, 32 сен  6 08:33 /dev/sdc
brw------- 1 root root 8, 33 сен  6 08:33 /dev/sdc1
brw------- 1 root root 8, 34 сен  6 08:33 /dev/sdc2
brw------- 1 root root 8, 48 сен  6 08:33 /dev/sdd
brw------- 1 root root 8, 49 сен  6 08:33 /dev/sdd1
brw------- 1 root root 8, 50 сен  6 08:33 /dev/sdd2
brw------- 1 root root 8, 64 сен  6 08:33 /dev/sde
brw------- 1 root root 8, 65 сен  6 08:33 /dev/sde1
brw------- 1 root root 8, 66 сен  6 08:33 /dev/sde2
brw------- 1 root root 8, 80 сен  6 08:33 /dev/sdf
brw------- 1 root root 8, 81 сен  6 08:33 /dev/sdf1
brw------- 1 root root 8, 82 сен  6 08:33 /dev/sdf2
brw------- 1 root root 8, 96 сен  6 08:33 /dev/sdg
brw------- 1 root root 8, 97 сен  6 08:33 /dev/sdg1
brw------- 1 root root 8, 98 сен  6 08:33 /dev/sdg2

Как всегда, разработчики ядра оказались умнее разработчиков
усерспейсных костылей.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Dmitry V. Levin]

On Mon, Feb 12, 2024 at 08:58:30AM +0300, Anton Farygin wrote:
> On 12.02.2024 01:12, Dmitry V. Levin wrote:
> > Кто-нибудь может мне рассказать, почему ядро до сих пор ещё разрешает
> > setuid(overflowuid)?  Это же по сути отменяет саму идею, заложенную
> > в overflowuid.
> >
> Сейчас при входе в систему доменным пользователем UID получается 32-х 
> битный.
> 
> overflow оно только на старых системах, где UID/GID 16-бит.

Всё обстоит несколько иначе.  Не готов читать лекцию, желающие могут
обратиться к первоисточнику самостоятельно:

linux$ git grep overflowuid
Documentation/admin-guide/sysctl/fs.rst:overflowgid & overflowuid
Documentation/admin-guide/sysctl/kernel.rst:overflowgid & overflowuid
Documentation/filesystems/idmappings.rst:third idmapping. The kernel will report unmapped ids as the overflowuid
drivers/gpu/drm/drm_ioctl.c:		client->uid = overflowuid;
fs/sysctls.c:		.procname	= "overflowuid",
fs/sysctls.c:		.data		= &fs_overflowuid,
fs/udf/super.c:	uopt.uid = make_kuid(current_user_ns(), overflowuid);
include/linux/highuid.h:extern int overflowuid;
include/linux/highuid.h:#define high2lowuid(uid) ((uid) & ~0xFFFF ? (old_uid_t)overflowuid : (old_uid_t)(uid))
include/linux/highuid.h:extern int fs_overflowuid;
include/linux/highuid.h:#define fs_high2lowuid(uid) ((uid) & ~0xFFFF ? (uid16_t)fs_overflowuid : (uid16_t)(uid))
include/linux/uidgid.h:		uid = overflowuid;
include/uapi/linux/bpf.h: * 		time-wait or a request socket instead), **overflowuid** value
include/uapi/linux/bpf.h: * 		is returned (note that **overflowuid** might also be the actual
kernel/sys.c:int overflowuid = DEFAULT_OVERFLOWUID;
kernel/sys.c:EXPORT_SYMBOL(overflowuid);
kernel/sys.c:int fs_overflowuid = DEFAULT_FS_OVERFLOWUID;
kernel/sys.c:EXPORT_SYMBOL(fs_overflowuid);
kernel/sysctl.c:		.procname	= "overflowuid",
kernel/sysctl.c:		.data		= &overflowuid,
kernel/user_namespace.c: *	If @kuid has no mapping in @targ overflowuid is returned.
kernel/user_namespace.c:		uid = overflowuid;
net/core/filter.c:		return overflowuid;


-- 
ldv

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Anton Farygin]

On 12.02.2024 13:34, Dmitry V. Levin wrote:
> Всё обстоит несколько иначе.

Ну да, но смысл от этого особо не меняется.

sysctl этот, судя по документации, для каких-то старых файловых систем 
нужен:

https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On Mon, Feb 12, 2024 at 01:50:27PM +0300, Anton Farygin wrote:
> On 12.02.2024 13:34, Dmitry V. Levin wrote:
> > Всё обстоит несколько иначе.
> 
> Ну да, но смысл от этого особо не меняется.
> 
> sysctl этот, судя по документации, для каких-то старых файловых систем
> нужен:
> 
> https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid

NFS с его логикой ремаппинга рута трудно назвать старой файловой
системой. :)

Более того, письмо Димы с цитатой git grep по ядру меня сподвигло узнать
вот об этом:

user_namespaces(7):
   Unmapped user and group IDs
       There  are various places where an unmapped user ID (group ID) may be exposed to user
       space.  For example, the first process in a new user namespace may call getuid(2) be‐
       fore a user ID mapping has been defined for the namespace.  In most  such  cases,  an
       unmapped  user  ID is converted to the overflow user ID (group ID); the default value
       for the overflow user ID (group ID) is 65534.  See the descriptions of /proc/sys/ker‐
       nel/overflowuid and /proc/sys/kernel/overflowgid in proc(5).

       The cases where unmapped IDs are mapped in this fashion include system calls that re‐
       turn user IDs (getuid(2), getgid(2), and similar), credentials passed over a UNIX do‐
       main socket, credentials returned by stat(2), waitid(2), and the System V  IPC  "ctl"
       IPC_STAT  operations,  credentials  exposed  by  /proc/pid/status  and  the  files in
       /proc/sysvipc/*, credentials returned via the si_uid field in the siginfo_t  received
       with  a signal (see sigaction(2)), credentials written to the process accounting file
       (see acct(5)), and credentials returned with POSIX message queue  notifications  (see
       mq_notify(3)).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 4356 bytes --]

On Mon, Feb 12, 2024 at 08:44:19AM +0300, Anton Farygin wrote:
> On 10.02.2024 18:23, Arseny Maslennikov wrote:
> > On Sat, Feb 10, 2024 at 05:06:13PM +0300, Anton Farygin wrote:
> > > On 10.02.2024 14:37, Arseny Maslennikov wrote:
> > > > xfsprogs-6.3.0-alt1
> > > > 	Verifying systemd units in /usr/src/tmp/xfsprogs-buildroot
> > > > 	044-verify-unit.brp: ERROR:"/lib/systemd/system/xfs_scrub@.service"  assumes overflowugid
> > > > 	credentials
> > > > xfsprogs	rider mike @qa
> > > чем так плох nobody для той операции, которую выполняет данный unit ?
> > nobody у нас скоро превратится в overflowuid, под которым ничего не
> > должно работать.
> Почему-то при этом в других дистрибутивах работает.

Это либо от халатности, либо по инициативе начинающих, наивных или
по-доброму ленивых админов "сам-себе-мейнтейнеров". Так-то и файл, на
который сказали chmod 777, точно так же доступен на чтение, как и файл с
режимом 644 или 600. "Ведь и так работает!"

> Или overflow uid сделаем
> только мы ?

Дебиан уже сделал:
# grep D /etc/os-release 
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
# getent passwd nobody
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
# echo $(</proc/sys/fs/overflowuid):$(</proc/sys/fs/overflowgid) 
65534:65534

Кто пользуется другими, может глянуть на других.

> > > Что-то я не пойму, какое решение предлагается в данном случае
> > Лучше всего завести для него отдельного пользователя (или, может, для
> > всех xfsprogs).
> 
> Возможно, но мне хотелось бы что бы заведение системного пользователя было
> осмысленно.

Смысл — в проведении границы между привилегиями этого сервиса и других,
а также границы с overflowuid.

> Возможно нам нужен пользователь не для xfs_scrub, а в целом для операций над
> FS ?

Это уж точно гораздо лучше nobody. Но по-прежнему непонятно, чем этот
случай заслуживает исключения.

А точно ли таких скрабберов, нынче сбрасывающих uid до чего попало, но
сохраняющих за собой обширный набор капов (AmbientCapabilities=), больше
одного?

> > Если это по какой-то причине невозможно, есть другие варианты:
> > * если учесть, что много что в юните закрыли, какого-нибудь daemon из
> >    головы /etc/passwd;
> Неизвестно, кто захочет и как использовать данный UID.
Мне тоже, но я подозреваю, что вообще никто, кроме, вероятно, дебиановского
варианта at(1), за которым помню такой артефакт. Я и пишу: "если завести
отдельного по какой-то причине невозможно". Предложения взять daemon,
disk, или резервировать новый uid для ухода за ФС — это всё уже попытки
изобрести компромисс.

> Да и демон - это не то, чем можно назвать xfs_scrub
Верно, но запускают эту программу именно в такой роли. Системдоиды
говорят "oneshot-сервис"; он безголовый, т. е. без {WAYLAND_,}DISPLAY= и
без контрольного терминала, и запускается сам по событию.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

On Mon, Feb 12, 2024 at 05:23:53PM +0300, Arseny Maslennikov wrote:
> On Mon, Feb 12, 2024 at 08:44:19AM +0300, Anton Farygin wrote:
> > Возможно, но мне хотелось бы что бы заведение системного пользователя было
> > осмысленно.

(в сторону) Чувствую, что надо это куда-то записать.

Замечаю, к сожалению, что в некоторых умах сложился нездоровый взгляд
на т. н. заведение системных пользователей:
* кажется, будто это сложное, мучительное дело (руками — да);
* кажется, будто ему нужно выделить и сопровождать какие-то ресурсы,
  вроде домашнего каталога, шелла, квот, gecos; будто от него будут
  порождаться какие-то сеансы с участием pam и logind; будто всё это —
  хрупкий стейт, захламляющий не только систему, но и голову
  администратора;
* этот стейт потом сложно удалить — а вдруг в ФС остались данные с этими
  uid и gid?

А на самом деле вопрос сводится к тому, чтобы называть вещи подходящими
именами. Здесь речи о _заведении пользователей_ нет, потому что нету
никаких пользователей и большинство соотв. типов ресурсов им не
требуется. Если эту процедуру назвать "резервирование UID и GID", сразу
весь ментальный морок спадает. "...С целью разделения привилегий". Этим
системным "пользователям" и имя-то не нужно, их имя выступает лишь
симлинком на выделенный по месту на машине численный ID, вносит
дополнительный удобный уровень косвенности. Понятия "сеанс",
"пароль/токен аутентификации", "домашний каталог", "начальный шелл" для
них, понятное дело, тем более не имеют смысла.

Институт sysusers вообще упрощает это дело чуть ли не до максимума: в
пакет со службой достаточно упаковать файл-конфиг. Но пока что нам не
судьба.

Останется лишь соображение о возможности потери стейта от удаления
записей о резервировании, но и эту проблему можно побороть, исключив
доступ сервису на запись во все места, кроме белого списка, и сделать
это решение общедистрибутивным. (Если бы в /etc/passwd можно было
записать строчку навроде "deleted uid N", это была бы половина решения)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Anton Farygin]

On 12.02.2024 17:33, Arseny Maslennikov wrote:
> Институт sysusers вообще упрощает это дело чуть ли не до максимума: в
> пакет со службой достаточно упаковать файл-конфиг. Но пока что нам не
> судьба.

Вы просто не так часто переносите файлы, принадлежащие вот таким образом 
заведённому системному пользователю с одной машины на другую.

Нужно резервирование UID, а не заведение системного пользователя. Это 
немного больше и важнее.

Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials"

[Vitaly Lipatov]

Arseny Maslennikov писал(а) 10.2.24 14:37:
> Hi!
> 
> В опубликованный сегодня Sisyphus вошёл новый rpm-build:
>> rpm-build - Scripts and executable programs used to build packages
>> * Thu Jan 11 2024 Arseny Maslennikov <arseny@altlinux> 4.0.4.195-alt1
>> - debuginfo: Changed compression format (--lzma2=dict=2MiB ->
>>   --check=crc32 --lzma2=dict=1MiB) of xz-compressed modules for 
>> compatibility
>>   with kmod >= 31 (thx asheplyakov@).
>> - Introduced brp-verify-unit to check sanity of systemd units included
>>   in built packages.
..
На всякий случай, не забыли ли
# grep nobody /lib/sysusers.d/basic.conf
# The nobody user/group for NFS file systems
g nobody 65534       -            -
u nobody 65534:65534 "Kernel Overflow User"     -

-- 
С уважением,
Виталий Липатов,
ALT Linux Team