From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <8b51c340-3818-4379-a3c4-65ebcbc7edc3@basealt.ru> Date: Mon, 12 Feb 2024 08:44:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru To: devel@lists.altlinux.org References: <1bb82ee2-b4d6-4245-9428-6f01ab19bb67@basealt.ru> From: Anton Farygin Organization: BaseALT In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] I: brp-verify-unit: "... assumes overflowugid credentials" X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2024 05:44:20 -0000 Archived-At: List-Archive: List-Post: 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, не получится. Верно, тоже не решение.