Bug 59308 - Различие в определении существовании группы между getgrnam и useradd
Summary: Различие в определении существовании группы между getgrnam и useradd
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: accountsservice (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-05-23 21:10 MSK by Vladimir Romanov
Modified: 2026-05-28 00:30 MSK (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Romanov 2026-05-23 21:10:41 MSK
getgrnam находит группу во всех источниках, описанных в nsswitch.conf
useradd учитывает только /etc/group

Из-за этого проверка существования группы может работать некорректно (https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L1863)

В ALT Atomic мы перешли на смешанные passwd/group, используя altfiles в nsswitch.conf (пакет libnss-altfiles).

nsswitch в атомарке:

passwd:     files altfiles systemd
shadow:     tcb files systemd
group:      files [SUCCESS=merge] altfiles [SUCCESS=merge] systemd
gshadow:    files systemd


Это было сделано для большего контроля над системой со стороны поставщика образа, минимизации дрифта UID/GUID и иных проблем. Мы используем декларативный формат, который описывает какие пользователи в какие группы входит и `apm system image sync-group` копирует, сопровождает или удаляеи по необходимости записи в /etc/group (так как /usr/lib/group записи редактировать нельзя)

При использовании мастера первоначальной настройки (ready-set или gnome-initial-setup) AccountsService при попытке создать пользователя возвращает ошибку 6 от useradd, так как группы, в которые должен быть добавлен пользователь, не существуют в /etc/group (но существуют для getgtnam)
Comment 1 Vladimir Romanov 2026-05-23 21:16:09 MSK
Также добавлю, что в Fedora Silverblue (и всех производных) тоже используется altfiles (но с ручных добавлением записей в /etc/group и с кучей suid'ов)

Там подобной проблемы нет, так как нет определения пользователей в спеке (понимаю, что не наш путь, просто для информации, "как у других работает") 
https://src.fedoraproject.org/rpms/accountsservice/blob/rawhide/f/accountsservice.spec#_60
Comment 2 Дмитрий 2026-05-23 21:37:20 MSK
Добавлю от себя для усиления аргументации данного issue

Я считаю что формирование списка групп в которые входит пользователь обязательно должно управляться механизмом сборки/установщиком/первичной настройкой системы так как это свойство исключительно характеризуется набором пакетов собираемого дистрибутива, а не спеком одного пакета в репозитории даже не привязанного к брендингам

Вот примеры как mkimage-profiles управляет группами на своей стороне:
https://altlinux.space/mkimage-profiles/mkimage-profiles/src/branch/master/features.in/deflogin

https://altlinux.space/mkimage-profiles/mkimage-profiles/search/branch/master?path=&q=xgrp+audio+video+camera&mode=exact
Comment 3 Vladimir Romanov 2026-05-26 13:27:46 MSK
Создал таск #419190:

- С обновлением accountsservice на свежую версию
- С портом на более понятную и удобную для тестов модель сопровождения
- С правками проблемы текущей баги, читая /etc/group напрямую без вызова getgrnam
Comment 4 Repository Robot 2026-05-28 00:30:14 MSK
accountsservice-26.12.8-alt1 -> sisyphus:

Tue May 26 2026 Vladimir Romanov <rirusha@altlinux> 26.12.8-alt1
- 26.12.8 (closes: #58899)
- Fixed creating user with ReadySet in ALT Atomic (closes: #59308).
- Port package to more classic gear way.