[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, не получится.
Верно, тоже не решение.