Created attachment 14363 [details] вкладка Пользователи дистубутив Fedora 38 Отсутствует очень полезная и привычная опция для пользователя Gnome "Автоматический вход" в Настройках вкладка "Пользователи". Можно ее активировать? Это вопрос достаточно популярен среди пользователей, который перешли с других дистрибутивов с рабочем окружением Gnome и не знают, что данная опция есть в программе "Центр управления системой" (Альт)
Весьма вероятно, виноват accountsservice.
Проблема в том, что accountsservice сообщает, что пользователь не является локальным. LocalAccount=false Для того, чтобы в этом убедиться выполните в терминале: # busctl monitor org.freedesktop.Accounts затем откройте центр настроек gnome и перейдите в раздел пользователи. В терминале в самом конце будет значение LocalAccount. Автоматический вход не доступен для нелокальных пользователей.
(Ответ для Антон Мидюков на комментарий #2) > Проблема в том, что accountsservice сообщает, что пользователь не является > локальным. LocalAccount=false > Для того, чтобы в этом убедиться выполните в терминале: > # busctl monitor org.freedesktop.Accounts > > затем откройте центр настроек gnome и перейдите в раздел пользователи. В > терминале в самом конце будет значение LocalAccount. > > Автоматический вход не доступен для нелокальных пользователей. В p10 LocalAccount=true и проблемы нет.
Можно собрать с выключенным флагом #ifdef HAVE_SHADOW_H Чтобы не учитывал /etc/shadow и тем самым не блокировал учётную запись, так как она есть в passwd, но отсутствует в альте в shadow, по логике account service это значит, что она для удалённого подключения и меняется сразу 2 флага, что она заблокирована и не локальная. Выключая всё для отображения в настройках гнома Gnome Settings реагирует только на заблокированность учётной записи тут.
Вопрос возникает, если он будет нужен для учёта в Alt Mobile например. Так как он выключит логику с shadow файлом. Но вроде Отключение требует просто убрать, shadow-utils (провайдер 'shadow.h'), как сборочную зависимость ``` # headers check_headers = [ 'paths.h', 'shadow.h', 'utmpx.h', ] foreach header: check_headers config_h.set('HAVE_' + header.underscorify().to_upper(), cc.has_header(header)) endforeach ```
(Ответ для Toxblh на комментарий #5) > Отключение требует просто убрать, shadow-utils (провайдер 'shadow.h'), как > сборочную зависимость > /usr/include/shadow.h предоставляется пакетом glibc-devel. И эту зависимость никак не убрать.
По итогу багу нашлась в коде, завёл issue в upstream: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/121 До исправления, можно сделать временное решение - отсортировать passwd, подняв пользователя на самый верх или сортировку по убыванию uid.
(Ответ для Toxblh на комментарий #7) > По итогу багу нашлась в коде, завёл issue в upstream: > https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/121 > > До исправления, можно сделать временное решение - отсортировать passwd, > подняв пользователя на самый верх или сортировку по убыванию uid. Это же не по этому багу, а по https://bugzilla.altlinux.org/48825
А они все связаны и можно объединять, но исправление в апстриме, конкретно эту не поправит. Вторая часть это признак локальности учётной записи, его можно расчёты можно перебить в файле, в моём случае `/var/lib/AccountsService/users/toxblh` Нужно дописать `LocalAccount=true`
Created attachment 15343 [details] Патч текущей версии. Так в целом, версии main и та, что последняя в релизе далеки друг от друга. Потому моё прошлое предложение исключить shadow.h, добавило бы проблем только, так как под тегом нету блоков больших исключающих логику shadow, как нам было бы нужно. Потому решил подготовить патч для мимикрии процесса, который нужен нам. Во первых - мы обнуляем все данные из shadow, будто у нас его и вовсе нет. При проходе закрывая проблему по тому, что протекает пользователь с прошлой итерации. Там теперь точно NULL. И второе признак локальности по коду по умолчанию считается, как локальный для всех, но после идёт проверка, есть ли пользователь из passwd в shadow. Мы же в users получим только список уже пользователей c uid => 1000 в user_classify_is_human благодаря этому фильтру из моего комментария на issue, но shadow теперь там будет пустой для всех, а значит все будут не локальными, потому добавляем else так что вернёт только реальных пользователей на системе. Но я ожидаю, что в реальности они всё ещё могут быть системными, так что логику установки локальности аккаунта оставляем, и устанавливаем признак не локальности на базе того, что пользователь не помечен в файле, как системный. Проверяться это будет в keyfile по флагу "SystemAccount" для аккаунтов с uid >= 1000, это нужно учитывать. Я не сильно погружался в Альт аккаунты, если он не устанавливает в файлах флаг системности, то мы можем получить аккаунты на странице входа больше, чем ожидаем, если они имеют uid>1000 и нормальный shell путь, то есть user_classify_is_human вернула, что это человек user_classify_is_human: https://gitlab.freedesktop.org/accountsservice/accountsservice/blob/68e8a5d3d57344e893becdd80a4ead48438717e8/src/user-classify.c#L117 Проверяться это будет в keyfile (user_get_system_account): https://gitlab.freedesktop.org/accountsservice/accountsservice/blob/15e6a4c3a2982bdc6619258af34f13ba0f71046f/src/user.c#L1087 Изначально SystemAccount читается из файла, что в var/lib/AccountsService/... https://gitlab.freedesktop.org/accountsservice/accountsservice/blob/15e6a4c3a2982bdc6619258af34f13ba0f71046f/src/user.c#L685
В целом можно и полностью удалить строчку user_update_local_account_property (user, g_hash_table_contains (local_users, name)); в проходе по пользователям, если таких в системе не ожидается или флаг SystemAccount не устанавливается в Альт управлением аккаунтами Тогда все точно будут считаться локальными.
(Ответ для Toxblh на комментарий #10) > И второе признак локальности по коду по умолчанию считается, как локальный > для всех, но после идёт проверка, есть ли пользователь из passwd в shadow. > Мы же в users получим только список уже пользователей c uid => 1000 в > user_classify_is_human благодаря этому фильтру из моего комментария на > issue, но shadow теперь там будет пустой для всех, а значит все будут не > локальными, потому добавляем else так что вернёт только реальных > пользователей на системе. Но я ожидаю, что в реальности они всё ещё могут > быть системными, так что логику установки локальности аккаунта оставляем, и > устанавливаем признак не локальности на базе того, что пользователь не > помечен в файле, как системный. Проверяться это будет в keyfile по флагу > "SystemAccount" для аккаунтов с uid >= 1000, это нужно учитывать. > По поводу локальных пользователей. Нам нужно определять локальный пользователь или нет (т.е. доменный) по принципу, прописан пользователь или нет в системе. Проверка на локальность сейчас не учитывает, что проверять нужно наличие записи не в /etc/shadow, а в /etc/tcb/*/shadow. Так как используется схема хранения паролей tcb. И стоит не забывать, что можно переключиться на использование традиционного shadow при помощи control. # control |grep tcb passwd tcb (tcb traditional restricted) tcb_chkpwd tcb (traditional tcb restricted) Поэтому нужно, видимо, учитывать используемую схему, и в зависимости от схемы проверять наличие записи в /etc/tcb/*/shadow или в /etc/shadow.
(Ответ для Антон Мидюков на комментарий #12) > (Ответ для Toxblh на комментарий #10) > > И второе признак локальности по коду по умолчанию считается, как локальный > > для всех, но после идёт проверка, есть ли пользователь из passwd в shadow. > > Мы же в users получим только список уже пользователей c uid => 1000 в > > user_classify_is_human благодаря этому фильтру из моего комментария на > > issue, но shadow теперь там будет пустой для всех, а значит все будут не > > локальными, потому добавляем else так что вернёт только реальных > > пользователей на системе. Но я ожидаю, что в реальности они всё ещё могут > > быть системными, так что логику установки локальности аккаунта оставляем, и > > устанавливаем признак не локальности на базе того, что пользователь не > > помечен в файле, как системный. Проверяться это будет в keyfile по флагу > > "SystemAccount" для аккаунтов с uid >= 1000, это нужно учитывать. > > > > По поводу локальных пользователей. Нам нужно определять локальный > пользователь или нет (т.е. доменный) по принципу, прописан пользователь или > нет в системе. > Проверка на локальность сейчас не учитывает, что проверять нужно наличие > записи не в /etc/shadow, а в /etc/tcb/*/shadow. Так как используется схема > хранения паролей tcb. > > И стоит не забывать, что можно переключиться на использование традиционного > shadow при помощи control. > > # control |grep tcb > passwd tcb (tcb traditional restricted) > tcb_chkpwd tcb (traditional tcb restricted) > > Поэтому нужно, видимо, учитывать используемую схему, и в зависимости от > схемы проверять наличие записи в /etc/tcb/*/shadow или в /etc/shadow. Спасибо за информацию. Тут по хорошему нужно в принципе дописывать логику использования tcb тогда c проверкой текущего режима с покрытием тестами. Я бы такое вынес в отдельное issue на дополнительную реализацию, а в рамках данного бага условился, что пользователь не меняет логики с стандартной на shadow. А есть примеры интеграции в Mate и KDE похожей логики? Я не нашёл документации к tcb по внедрению его в другие приложения. Только код сам в себе https://github.com/openwall/tcb/blob/main/include/tcb.h и там не густо.
Подписываю Евгения Синельникова.
Created attachment 15572 [details] патч протекающих shadow users Патч которым починил поведение на ожидаемое. Больше shadow пользователи предыдущие перед нашим, не влияют на него. Ну и тесты пофиксил, а то не проходили при сборке
(Ответ для Toxblh на комментарий #13) > А есть примеры интеграции в Mate и KDE похожей логики? KDE использует accountsservice.
(Ответ для Toxblh на комментарий #15) > Создано вложение 15572 [details] [подробности] > патч протекающих shadow users > > Патч которым починил поведение на ожидаемое. Больше shadow пользователи > предыдущие перед нашим, не влияют на него. > > Ну и тесты пофиксил, а то не проходили при сборке Наложил патч https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/147 на main из апстрима. Никакого положительного эффекта не принесло. Можно попробовать оз этого таска: https://git.altlinux.org/tasks/341187/
(Ответ для Alexey Shabalin на комментарий #17) > (Ответ для Toxblh на комментарий #15) > > Создано вложение 15572 [details] [подробности] > > патч протекающих shadow users > > > > Патч которым починил поведение на ожидаемое. Больше shadow пользователи > > предыдущие перед нашим, не влияют на него. > > > > Ну и тесты пофиксил, а то не проходили при сборке > > Наложил патч > https://gitlab.freedesktop.org/accountsservice/accountsservice/-/ > merge_requests/147 > на main из апстрима. > Никакого положительного эффекта не принесло. > Можно попробовать оз этого таска: > https://git.altlinux.org/tasks/341187/ Почему не принесло? Пользователь на экране появляется.
(Ответ для Антон Мидюков на комментарий #18) > (Ответ для Alexey Shabalin на комментарий #17) > > (Ответ для Toxblh на комментарий #15) > > > Создано вложение 15572 [details] [подробности] > > > патч протекающих shadow users > > > > > > Патч которым починил поведение на ожидаемое. Больше shadow пользователи > > > предыдущие перед нашим, не влияют на него. > > > > > > Ну и тесты пофиксил, а то не проходили при сборке > > > > Наложил патч > > https://gitlab.freedesktop.org/accountsservice/accountsservice/-/ > > merge_requests/147 > > на main из апстрима. > > Никакого положительного эффекта не принесло. > > Можно попробовать оз этого таска: > > https://git.altlinux.org/tasks/341187/ > > Почему не принесло? Пользователь на экране появляется. Но этот баг оно и не фиксит. Фиксит только 48825
Зачем у нас для проверки "локальности", вообще, используется /etc/shadow? Насколько я понимаю, единственным достоверным источником локальности может быть тот nss-модуль, который отвечает за локальных пользователей - files, который напрямую работает через /etc/passwd: $ getent passwd admin admin:x:500:500:Local administrator:/home/admin:/bin/bash $ grep ^admin /etc/passwd admin:x:500:500:Local administrator:/home/admin:/bin/bash Среди новых технологий, которые стоит выделить отдельно - это sssd в режиме управления локальными пользователями, где /etc/passwd и модуль files могут использоваться, как fallback. - https://sssd.io/docs/architecture.html - https://docs.pagure.org/sssd.sssd/design_pages/files_provider.html Но даже в этом случае: “Files” data provider to serve contents of /etc/passwd and /etc/group. По какой причине, вообще, используется /etc/shadow - непонятно. Детали реализации работы с аутентификацией, по уму, должны быть скрыты за интерфейсом PAM и системными приложениями. И оно делает вид даже что работает, только не работает: $ busctl call org.freedesktop.Accounts /org/freedesktop/Accounts/User500 org.freedesktop.Accounts.User SetPassword "ss" "Qw1234567811" "11" $ su - admin Password: su: Authentication failure А вот, что оно делает, по сути (это становится понятно на примере закешированного доменного пользователя): $ busctl call org.freedesktop.Accounts /org/freedesktop/Accounts/User758801104 org.freedesktop.Accounts.User SetPassword "ss" "Qw12345678" "Qw" Call failed: running '/usr/sbin/chpasswd' failed: Дочерний процесс завершился с кодом 1 То есть оно тупо запускает chpasswd. Из-под рута, конечно. При этом в лоб оно работает: $ sudo chpasswd admin:Qw12345600 $ su - admin Password: [admin@xdt ~]$ ________________________ Собственно, а причем тут Автоматический вход" в Настройках вкладка "Пользователи" в рабочем окружении Gnome? Вероятно, всё в том же. В неразумной логике эвристики по выявлению локальности пользователей с помощью грязных хаков с хождением вручную в /etc/shadow и предположением о "знании" деталей реализации. Отмечу ещё, что NSS и PAM должны быть взаимоувязаны. В PAM-стеке мы используем модуль pam_localuser.so для выявления "локальности", а этот модуль тоже рассчитывает "локальность" исключительно из содержимого /etc/passwd: $ grep password /etc/pam.d/system-auth password [success=4 perm_denied=ignore default=die] pam_localuser.so password [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet password [default=1] pam_permit.so password substack system-auth-sss-only password [default=1] pam_permit.so password substack system-auth-local-only password substack system-auth-common _________ Итого, предлагаю выпилить из accountsservice все костыли на предмет использования /etc/shadow.
(Ответ для Evgeny Sinelnikov на комментарий #20) > Зачем у нас для проверки "локальности", вообще, используется /etc/shadow? > --- > Собственно, а причем тут Автоматический вход" в Настройках вкладка > "Пользователи" в рабочем окружении Gnome? > --- > Вероятно, всё в том же. В неразумной логике эвристики по выявлению > локальности пользователей с помощью грязных хаков с хождением вручную в > /etc/shadow и предположением о "знании" деталей реализации. То почему они используют shadow описали в комментарии https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L286 приведу цитату /* Local user accounts (currently defined as existing in * /etc/shadow, so sites that rsync NIS/LDAP users into * /etc/passwd don't get them all treated as local) * username -> copy of shadow_entry_buffers */ У нас оно из апстрима и используется именно по этому. А у них, чтобы расширить логику локальности, включая удалённых пользователей. > --- > Итого, предлагаю выпилить из accountsservice все костыли на предмет > использования /etc/shadow. Или же использовать ту же эвристику но поверх tcb?
Я в таске #344134 для теста собрал с отключенным HAVE_SHADOW_H. Автологин на десктопе работает. Но пользователи по прежнему LocalAccount=false.
(Ответ для Alexey Shabalin на комментарий #22) > Я в таске #344134 для теста собрал с отключенным HAVE_SHADOW_H. > Автологин на десктопе работает. Но пользователи по прежнему > LocalAccount=false. Автологин и работал. Так что ничего не поменялось. Тоже проверил.
Поскольку на форуме forum.altlinux.org писать нельзя (одобрения создания учетной записи нужно ждать месяцы), то добавляю в одну из ближайших схожих по тематике багтрекера. Система alt Linux Woarkstation K 10.3 (стабильная, в рамках аналога багов 48825,47726 версия accountsservice 0.6.55, lightdm 1.30.0) Установка пакетов brltty (orca) и fwupd (fwupd, fwupd_efi, plasma5-discover-fwupd) с использованием хеширования через tcb ведет как к описанной в данном баге проблеме, так и к смежным (описанным на форуме): - не отображается пользователь на экране графического входа (lightdm), при этом доступен вход через ручной ввод имени пользователя - проблемы с управлением пользователями. В /etc/shadow создаются соответствующие пакетам заблокированные пользователи, управление которыми стандартными средствами недоступно. Например: 1. Устанавливаем brltty и/или fwupd 2. Проверяем, что в /etc/shadow появились проблемные аккаунты -- brltty:!*:19808:::::: fwupd-refresh:!*:19808:::::: -- 3. Проверяем 3.1. После перезагрузки на экране вместо отображения пользователей отображается поле ввода имени пользователя (баг 48825) 3.2 Удаление пакетов ничего не меняет. 3.3. Штатные средства (например "userdel brltty" и аналоги с редактированием пользователей бесполезны) Решение удалением (по-умолчанию на свежеустановленном Alt Linux права на shadow 400, на /etc/passwd 644, а vipw бесполезен, так что через vi, nano и тп действуем вручную) sudo apt-get remove brltty fwupd # (удаляем проблемные пакеты) sudo chmod 600 /etc/shadow # (открываем доступ к редактированию shadow) sudo vi /etc/passwd # (удаляем строки с brltty и fwupd-refresh) sudo vi /etc/shadow # (удаляем строки с brltty и fwupd-refresh) sudo chmod 400 /etc/shadow # (возвращаем исходные права) # соответственно, так можно корректно избавиться от пакетов и их следов в системе. Решение костылем (без удаления пакетов, ибо, если они нужны в текущей стабильной версии - их установка после удаления и очистки вернет баг с заблокированными учетными записями) sudo chmod 600 /etc/shadow sudo vi /etc/shadow # (удаляем блокировку (восклицательный знак) с brltty и fwupd-refresh, т.е. вместо "brltty:!*:19822::::::" получится "brltty:*:19822::::::" и аналогично у fwupd-refresh) sudo chmod 400 /etc/shadow # (возвращаем исходные права) # это именно костыль, так как правило блокировки "!" и создания учетки без выставления пароля "!!" никуда не денутся, так что решать нужно на уровне tcb и всех зависимых пакетов
Видимо, надо отрывать accountsservice от /etc/shadow или править, чтоб лазил в /etc/tcb/ .
Отвязывать, полагаю, - не вариант: могут возникнуть проблемы совместимости. А вот сделать затычку обратной совместимости - будет полезно. Что-то типа (это костыль-пример, а не рекомендация к применению на рабочей системе) 1. Проверить /etc/shadow при создании $username в обход tcb на предмет наличия блокировки (sed/grep и тп по "^$username\:\!"). 2. При наличии, перенести его в tcb ( mkdir /etc/tcb/%username && grep ^$username\:\! /etc/shadow > /etc/tcb/$username/shadow && chmod 600 /etc/shadow && sed -i '/$username\:\!/d' /etc/shadow && chmod 400 /etc/shadow && chown -R $username /etc/tcb/$username:auth ) Как простой временный вариант - достаточно добавить патч в проблемные пакеты (создающие таких пользователей) - это легко и оперативно, а в долговременном нужно смотреть код всех завязок на accountservice-tcb-pam и тп. Т.е. быстрый вариант: выпустить минорное обновление к пакетам с патчем Долговременный вариант: поставить аудит-триггер для всех импортируемых на время исправления работы tcb, зависимых и действующих в обход.
(Ответ для JcVai на комментарий #26) > Отвязывать, полагаю, - не вариант: могут возникнуть проблемы совместимости. Вот у Вас проблема на p10? Вы на Сизифе проверяли? На Сизифе описанную Вами проблему исправили.
(Ответ для JcVai на комментарий #26) > Отвязывать, полагаю, - не вариант: могут возникнуть проблемы совместимости. У нас /etc/shadow только для этого и существует, но, как видите, в этом случае не работает, т.е. надо патчить accountsservice для использования /etc/tcb/*/shadow.
(Ответ для Антон Мидюков на комментарий #27) > На Сизифе описанную Вами проблему исправили. Значит, надо переносить в p10.
> > На Сизифе описанную Вами проблему исправили. > Значит, надо переносить в p10. Если там есть эта проблема.
(Ответ для Антон Мидюков на комментарий #27) > Вот у Вас проблема на p10? Вы на Сизифе проверяли? На Сизифе описанную Вами > проблему исправили. К сожалению в работе могу применять только стабильные сборки, да и сам в никсах на уровне пользователя, так что да, ветка p10 (K 10.3 Sorbaronia Mitschurinii), на Сизифе не проверял. Если проблема уже решена, то, действительно, остается только ждать внедрения. Прошу прощения за "оффтоп" мимо темы.
(Ответ для JcVai на комментарий #31) > (Ответ для Антон Мидюков на комментарий #27) > > Вот у Вас проблема на p10? Вы на Сизифе проверяли? На Сизифе описанную Вами > > проблему исправили. > К сожалению в работе могу применять только стабильные сборки, да и сам в > никсах на уровне пользователя, так что да, ветка p10 (K 10.3 Sorbaronia > Mitschurinii), на Сизифе не проверял. Если проблема уже решена, то, > действительно, остается только ждать внедрения. Прошу прощения за "оффтоп" > мимо темы. Пожалуйста, заведите багу на p10, а этот баг добавьте в см. также.
