60591 2026-09-17 12:39:18 +0300 sssd_be падает (SIGSEGV) при обработке GPO с пустыми gPCMachineExtensionNames 2026-09-17 12:39:18 +0300 1 1 4 Development Sisyphus sssd unstable x86_64 Linux NEW P5 major --- 1 rider sin asheplyakov iv shaba sin slev qa-sisyphus oldest_to_newest 299424 0 rider 2026-09-17 12:39:18 +0300 sssd_be завершается по SIGSEGV при обработке групповой политики, у которой пусты атрибуты gPCMachineExtensionNames/gPCUserExtensionNames. Именно так GPO выглядит в LDAP сразу после создания через `samba-tool gpo create` (CSE-атрибуты проставляет уже редактор политик, admc/gpui). Стенд (клоны шаблонов poligon, dist-upgrade 2026-09-17, x86_64): - DC: клон 3125 (sisyphus-server, textmode), samba-dc-4.22.11-alt3, домен TEST.ALT (`samba-tool domain provision --realm=TEST.ALT --dns-backend=SAMBA_INTERNAL --server-role=dc --use-rfc2307`, уровень леса/домена 2008 R2). - Клиент: клон 3138 (sisyphus-workstation), сеанс MATE (mate-default-1.26.0-alt3), вход через lightdm; sssd-2.12.0-alt1 (sssd-ad-2.12.0-alt1), samba-client-4.22.11-alt3, gpupdate-0.16.3-alt1. Ввод в домен: `system-auth write ad TEST.ALT client TEST administrator '<пароль>'`, `net ads testjoin` -> Join is OK. Шаги: 1. На DC создать и привязать политику штатными средствами samba: samba-tool gpo create 'gp-test' -U administrator samba-tool gpo setlink 'DC=test,DC=alt' '{GUID}' -U administrator У созданного так объекта в LDAP gPCMachineExtensionNames и gPCUserExtensionNames пусты. 2. На клиенте выполнить вход доменным пользователем (обработка GPO провайдером ad в sssd_be). Фактический результат: sssd_be падает с SIGSEGV (segfault виден в `journalctl -k`), обработка политик не доходит до конца. Проверка от противного: после того как тому же GPO в LDAP были проставлены CSE-GUID реестрового расширения gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F72-3407-48AE-BA88-E8213C6761F1}] падения прекратились. Клиент, DC и сценарий входа при этом не менялись — отличается только этот атрибут. Ожидаемый результат: GPO без CSE-атрибутов игнорируется или обрабатывается как пустой (в худшем случае с диагностикой в журнале), sssd_be не падает. Падение бэкенда ломает разрешение имён и доменную аутентификацию до его перезапуска, и достаточно одной политики, созданной из командной строки, чтобы это получить. Оговорка о полноте данных: находка попутная (ретест багов gpupdate), стенд уже удалён — backtrace sssd_be и точная строка `kernel: sssd_be[...]: segfault at ...` не сохранены, есть только наблюдавшийся факт падения и то, что оно ушло после простановки CSE. Готов поднять стенд и снять core/backtrace, если это нужно для разбора. Апстрим: точного тикета про падение не нашёл. Ближайшее по условию — https://pagure.io/SSSD/sssd/issue/3114 (gPCMachineExtensionNames без GUID ломает обработку GPO, там речь о сбое разбора, не о SIGSEGV); отдельно есть https://github.com/SSSD/sssd/issues/6790 (SIGSEGV, но в gpo_child и по другой причине) и https://github.com/SSSD/sssd/pull/844 (исправления обработки GPO, созданных Samba DC).