| Summary: | Различие в определении существовании группы между getgrnam и useradd | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vladimir Romanov <rirusha> |
| Component: | accountsservice | Assignee: | Alexey Shabalin <shaba> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P5 | CC: | dmitry, rirusha, shaba |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
|
Description
Vladimir Romanov
2026-05-23 21:10:41 MSK
Также добавлю, что в Fedora Silverblue (и всех производных) тоже используется altfiles (но с ручных добавлением записей в /etc/group и с кучей suid'ов) Там подобной проблемы нет, так как нет определения пользователей в спеке (понимаю, что не наш путь, просто для информации, "как у других работает") https://src.fedoraproject.org/rpms/accountsservice/blob/rawhide/f/accountsservice.spec#_60 Добавлю от себя для усиления аргументации данного 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 Создал таск #419190: - С обновлением accountsservice на свежую версию - С портом на более понятную и удобную для тестов модель сопровождения - С правками проблемы текущей баги, читая /etc/group напрямую без вызова getgrnam |