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= и
без контрольного терминала, и запускается сам по событию.