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