Блокировка экрана работает один раз. На второй в wayland сессии видим черный экран с курсором, а в x11 сессии - остается неактивный рабочий стол и курсор. Разблокировать невозможно. Блокировка экрана нормально работала до последнего обновления в p11. nvidia (570), если что.
Уточните, пожалуйста, характеристики вашего компьютера. Приложите вывод # inxi -F
Какая версия пакета kscreenlocker ?
Created attachment 18007 [details] inxi -F
(Ответ для Sergey V Turchin на комментарий #2) > Какая версия пакета kscreenlocker ? # rpm -q kscreenlocker kscreenlocker-6.3.2-alt1.x86_64
Процесс kscreenlocker не завершает работу после разблокировки, поэтому новый не может запуститься и ждёт на чёрном экране. Это связано с обновлением пакета pam_pkcs11. Хотя, в Sisyphus было починено в kscreenlocker-6.2.5-alt2 в файле /etc/pam.d/kde-smartcard добавлением опций wait_for_card card_only. У вас случайно не используется pam_pkcs11?
(Ответ для Sergey V Turchin на комментарий #5) > Процесс kscreenlocker не завершает работу после разблокировки, поэтому новый > не может запуститься и ждёт на чёрном экране. > > Это связано с обновлением пакета pam_pkcs11. > Хотя, в Sisyphus было починено в kscreenlocker-6.2.5-alt2 в файле > /etc/pam.d/kde-smartcard добавлением опций wait_for_card card_only. > > У вас случайно не используется pam_pkcs11? Содержимое /etc/pam.d/kde-smartcard: #%PAM-1.0 auth [success=done ignore=ignore default=die] pam_pkcs11.so wait_for_card card_only auth substack system-auth-common account include system-auth-common password include system-auth-common session include system-auth-common smartcard не использую
(Ответ для Sergey V Turchin на комментарий #5) > Процесс kscreenlocker не завершает работу после разблокировки, поэтому новый > не может запуститься и ждёт на чёрном экране. Так и есть. Если после разблокировки убить /usr/libexec/kscreenlocker_greet, блокируется/разблокируется нормально.
Платформа: alt-kworkstation p11 x86_64 Пакеты: kscreenlocker-6.3.2-alt1.x86_64 nvidia_glx_570.124.04-570.124.04-alt273.x86_64 kernel-image-6.12-6.12.17-alt1.x86_64 Стенды: MSI MAG H670 NVIDIA GeForce GT 1030 [NVIDIA GP108] Gigabyte B760 DS3H RTL NVIDIA GeForce RTX 4060 Ti [NVIDIA AD106] Wayland сессия не запускается из-за бага https://bugzilla.altlinux.org/52744 Проверял в X11, ошибок с неактивным рабочим столом не обнаружено, 5 из 5 раз блокировка/разблокировка проходит успешно
(Ответ для Starodumoff Ilya на комментарий #7) > (Ответ для Sergey V Turchin на комментарий #5) > > Процесс kscreenlocker не завершает работу после разблокировки, поэтому новый > > не может запуститься и ждёт на чёрном экране. > > Так и есть. Если после разблокировки убить /usr/libexec/kscreenlocker_greet, > блокируется/разблокируется нормально. А что происходит, если в /etc/security/pam_pkcs11/pam_pkcs11.conf, в список screen_savers добавить kde-smartcard ? Поведение меняется?
(Ответ для manowar@altlinux.org на комментарий #9) > (Ответ для Starodumoff Ilya на комментарий #7) > > (Ответ для Sergey V Turchin на комментарий #5) > > > Процесс kscreenlocker не завершает работу после разблокировки, поэтому новый > > > не может запуститься и ждёт на чёрном экране. > > > > Так и есть. Если после разблокировки убить /usr/libexec/kscreenlocker_greet, > > блокируется/разблокируется нормально. > > А что происходит, если в /etc/security/pam_pkcs11/pam_pkcs11.conf, в список > screen_savers добавить kde-smartcard ? Поведение меняется? Хм... Сначала хотел написать, что то же самое поведение. Я еще несколько часов назад поправил pam_pkcs11.conf как в https://bugzilla.altlinux.org/show_bug.cgi?id=53128#c8 Еще раз проверил, на всякий случай. Оказалось, опечатался и вместо зяпятой после xcreensaver поставил "m" :) Проверил - теперь работает. Несколько раз блокировал/разблокировал и в wayland и в x11 сессиях.
Получается, что виснет внутри pam_pkcs11.so. Ну а как ему не виснуть, если он ожидает вставки смарт-карты? Получается следующая история: с той конфигурацией, с которой у вас сейчас работает, чёрный экран будет у того пользователя, который действительно захочет использовать смарт-карту. То есть, это не решение проблемы, а её обход для тех, кому pam_pkcs11.so не нужен в принципе.
Вроде ж работает, если внести "kde-smartcard" в список screen_savers в pam_pkcs11.conf? Кстати, ни один элемент из списка в данный момент там не соответствует KDE6.
Проверил - необязательно выставлять card_only и wait_for_card в true. Достаточно kde-smartcard в списке screen_savers.
(Ответ для manowar@altlinux.org на комментарий #11) > Получается, что виснет внутри pam_pkcs11.so. Ну а как ему не виснуть, если > он ожидает вставки смарт-карты? Получается следующая история: с той > конфигурацией, с которой у вас сейчас работает, чёрный экран будет у того > пользователя, который действительно захочет использовать смарт-карту. То > есть, это не решение проблемы, а её обход для тех, кому pam_pkcs11.so не > нужен в принципе. Так и есть, это обход проблемы за счет того, что ограничивается количество сценариев, когда появляется ошибка в pam_pkcs11 и это "ломает" блокировку, но если будет сценарий, в котором ошибка в pam_pkcs11 появится - проявится и проблема блокировщика. Так например, мы все еще можем получить эту ошибку, если пользователь вошел по токену, изменил используемый модуль в pam_pkcs11.conf (параметр use_pkcs11_module), перезапустил pcscd.service и дважды заблокировал экран. Маловероятный сценарий, который, однако, показывает, что проблема все еще есть. Обход работает, если в /etc/pam.d/kde-smartcard установлены параметры wait_for_card и card_only и вместе с этим kde-smartcard указан в скринсейверах в pam_pkcs11.conf. Если установлено что-то одно - ошибка продолжит проявляться. Работает, как мне кажется, за счет того, что отключает переход к модулю pam_pkcs11, если пользователь вошел с помощью пароля. Видимо, как раз отключение PAM_IGNORE (для исправления уязвимого поведения) привело к появлению проблемы блокировки. Обход ограничивает достаточно большое количество сценариев, подробнее проверки расписала в https://bugzilla.altlinux.org/show_bug.cgi?id=53128#c27 Т.к. корень проблемы все еще присутствует, переоткрываю ошибку. Если данного обхода проблемы достаточно, и исправлять некорректную реакцию блокировщика на возникновение ошибки в pam_pkcs11 не планируется, прошу сказать об этом или перевести в wontfix.
Перевожу на Sisyphus, т.к. в pam_pkcs11.conf по умолчанию пока не указан kde-smartcard в скринсейверах, и проблема воспроизводится, даже если просто вставить токен и дважды заблокировать экран.
Алёна, спасибо за такое обширное тестирование! Однако, есть несколько комментариев. > Видимо, как раз отключение PAM_IGNORE (для исправления уязвимого поведения) привело к появлению проблемы блокировки. Да, смысл обхода в том, что заставляем pam_pkcs11.so возвращать PAM_IGNORE. Думаю, понятно, что если мы по тем или иным причинам хотим задействовать pam_pkcs11.so, то PAM_IGNORE нам никак не подходит. Иными словами, данный обход равноценен простому отключению pam_pkcs11.so. > Обход работает, если в /etc/pam.d/kde-smartcard установлены параметры wait_for_card и card_only и вместе с этим kde-smartcard указан в скринсейверах в pam_pkcs11.conf. Однако тут есть один момент: список скринсейверов обрабатывается только, если в окружении пользовательского сеанса установлена переменная PKC11_LOGIN_TOKEN_NAME. Для KDE это нужно проверить. Проверить следующим образом: 1. зайти в систему по токену; 2. открыть терминал и ввести команду env | grep PKC11_LOGIN_TOKEN_NAME Переменная должна иметь не пустое значение (обычно там имя токена). Если окажется, что данная переменная не выставлена или пустая, то значит добавлять kde-smartcard в screen_savers нельзя. Если его туда добавить, то всегда будет возвращаться PAM_IGNORE. И разблокировать экран, используя токен, будет невозможно. Если же PKC11_LOGIN_TOKEN_NAME в сеансе KDE присутствует (при входе в систему по токену), то в этом случае нужно проверить, есть проблема с чёрным экраном. Насколько я понял, этой проблемы нет, если pam_pkcs11.so возвращает PAM_SUCCESS (так ли это?). Значит, нужно тем или иным способом добиться того, чтобы он возвращал ошибку (к примеру, поломать токен, ну не физически, конечно).
>2. открыть терминал и ввести команду Для рутокена: # env | grep PKC11_LOGIN_TOKEN_NAME PKC11_LOGIN_TOKEN_NAME=Rutoken Но на данный момент разблокировать токен, используя экран, нельзя, все время висит надпись "или используйте смарткарту", блокировщик на подключение токена никак не реагирует. >Если же PKC11_LOGIN_TOKEN_NAME в сеансе KDE присутствует (при входе в систему по токену), то в этом случае нужно проверить, есть проблема с чёрным экраном. Насколько я понял, этой проблемы нет, если pam_pkcs11.so возвращает PAM_SUCCESS (так ли это?). Значит, нужно тем или иным способом добиться того, чтобы он возвращал ошибку (к примеру, поломать токен, ну не физически, конечно). Выше указала сценарий, когда "ломают" конфиг pam_pkcs11, тогда проблема с черным экраном возвращается. >Так например, мы все еще можем получить эту ошибку, если пользователь вошел по токену, изменил используемый модуль в pam_pkcs11.conf (параметр use_pkcs11_module), перезапустил pcscd.service и дважды заблокировал экран. С токеном попробовала сценарий с битым сертификатом, разблокировщик не выдал черного экрана, токен не воспринимает. Удалила ключи с токена - аналогично. Пробовала вставить другой токен, разблокировщик опять не выдал черного экрана и токен не воспринял. Возможно, что несмотря на имя в переменной, kde-smartcard все равно возвращает PAM_IGNORE.
(Ответ для Белая Алёна на комментарий #17) > блокировщик на подключение токена никак не реагирует. При этом поле ввода пароля отображено?
(Ответ для Белая Алёна на комментарий #17) > Возможно, что несмотря на имя в переменной, kde-smartcard все равно > возвращает PAM_IGNORE. Это можно проверить используя pamtester: # pamtester kde-smartcard testuser authenticate Дополнительно стоит в pam_pkcs11.conf включить debug.
(Ответ для manowar@altlinux.org на комментарий #19) > Это можно проверить используя pamtester: > > # pamtester kde-smartcard testuser authenticate > > Дополнительно стоит в pam_pkcs11.conf включить debug. Прикладываю вывод $ pamtester kde-smartcard test authenticate с включённым debug (Ответ для zerg@altlinux.org на комментарий #18) > При этом поле ввода пароля отображено? Да
Created attachment 18147 [details] $ pamtester kde-smartcard test authenticate
Created attachment 18148 [details] Окно блокировки
Из лога pamtester видно, что возвращается PAM_SUCCESS. А что мы хотели этим проверить? :)
kscreenlocker-6.5.5-alt1 pam_pkcs11-0.6.13.1-alt1 Ключевая проблема - зависание kscreenlocker при появлении определенной ошибки, воспроизводится. Например, как в ситуации, описанной в комментарии 14. Лог ситуации прикладываю ниже: $ pamtester kde-smartcard test authenticate Найден Токен. Добро пожаловать, Рутокен ЭЦП 3.0 0! Введите PIN-код токена Токен: Verifying certificate... Checking signature... pamtester: successfully authenticated [test@education-11-0-x86-64-kde-20260209 ~]$ pamtester kde-smartcard test authenticate DEBUG:pam_pkcs11.c:283: Is it a screen saver? DEBUG:pam_pkcs11.c:327: explicit username = [test] DEBUG:pam_pkcs11.c:337: loading pkcs #11 module... DEBUG:pkcs11_lib.c:1000: PKCS #11 module = [/usr/lib64/opensc-pkcs11.so] DEBUG:pkcs11_lib.c:1016: module permissions: uid = 0, gid = 0, mode = 644 DEBUG:pkcs11_lib.c:1026: loading module /usr/lib64/opensc-pkcs11.so DEBUG:pkcs11_lib.c:1034: getting function list DEBUG:pam_pkcs11.c:353: initialising pkcs #11 module... DEBUG:pkcs11_lib.c:1179: module information: DEBUG:pkcs11_lib.c:1180: - version: 2.20 DEBUG:pkcs11_lib.c:1181: - manufacturer: OpenSC Project DEBUG:pkcs11_lib.c:1182: - flags: 0000 DEBUG:pkcs11_lib.c:1183: - library description: OpenSC smartcard framework DEBUG:pkcs11_lib.c:1184: - library version: 0.26 DEBUG:pkcs11_lib.c:1076: number of slots (a): 1 DEBUG:pkcs11_lib.c:1099: number of slots (b): 1 DEBUG:pkcs11_lib.c:1111: slot 1: DEBUG:pkcs11_lib.c:1121: - description: Aktiv Rutoken ECP 00 00 DEBUG:pkcs11_lib.c:1122: - manufacturer: Aktiv DEBUG:pkcs11_lib.c:1123: - flags: 0007 DEBUG:pkcs11_lib.c:1125: - token: ERROR:pam_pkcs11.c:357: init_pkcs11_module() failed: C_GetTokenInfo() failed: 0x000000E1 Error 2304: PKCS#11 module could not be initialized. pamtester: Службе проверки подлинности не удается загрузить сведения аутентификации По результату команды мы получаем ошибку и должны по сути выйти в authenification failure. Как я понимаю, в этот момент как раз не должно быть зависания, должен быть переход к другому способу аутентификации. Но видимо что-то (вероятно pam_pkcs11.so, согласно комментарию 11) продолжает ожидать вставки токена и удерживает процесс kscreenlocker, отчего и появляется черный экран.
(Ответ для Белая Алёна на комментарий #24) > ... > ERROR:pam_pkcs11.c:357: init_pkcs11_module() failed: C_GetTokenInfo() > failed: 0x000000E1 > Error 2304: PKCS#11 module could not be initialized. > pamtester: Службе проверки подлинности не удается загрузить сведения > аутентификации Я правильно понимаю, что pamtester завершает работу и не висит? > По результату команды мы получаем ошибку и должны по сути выйти в > authenification failure. Как я понимаю, в этот момент как раз не должно быть > зависания, должен быть переход к другому способу аутентификации. > Но видимо что-то (вероятно pam_pkcs11.so, согласно комментарию 11) > продолжает ожидать вставки токена и удерживает процесс kscreenlocker, отчего > и появляется черный экран. Если бы он ждал, то он ждал бы и в сеансе pamtester тоже. А в логе было бы сообщение "Please insert your smart card...". В связи с этим вопросы по последнему сеансу тестирования: 1. Был ли "kde-smartcard" добавлен в список "screen_savers" в pam_pkcs11.conf? 2. Если да, то пробовали ли выставлять PKC11_LOGIN_TOKEN_NAME=Rutoken и после этого запускать pamtester? 3. Какого поведения мы всё-таки хотим добиться? pam_pkcs11.so в самом деле может быть настроен на ожидание вставки смарт-карты. Но это лишь одна из его функций, использовать которую не обязательно. Между тем, pam_pkcs11.so может возвращать ошибку аутентификации, если карта не вставлена, ведь без карты нельзя аутентифицировать пользователя. Таким образом, я веду к тому, что обращение к pam_pkcs11.so нельзя рассматривать как рутину, оно не должно быть беспричинным и бесцельным. Если хранитель экрана обращается к pam_pkcs11.so, то что предполагается от него получить в данном сценарии тестирования (и почему)?
> Я правильно понимаю, что pamtester завершает работу и не висит? Да > 1. Был ли "kde-smartcard" добавлен в список "screen_savers" в pam_pkcs11.conf? Да > 2. Если да, то пробовали ли выставлять PKC11_LOGIN_TOKEN_NAME=Rutoken и после этого запускать pamtester? Переменная выставляется автоматически, если вход совершен по рутокену. В момент прогона pamtestser она была установлена > 3. Какого поведения мы всё-таки хотим добиться? Выявить первопричину проблемы и исправить ее. Для этого я в каком то смысле искусственно создаю ситуацию, когда проблема проявляется. Возможно, это вовсе излишне, и достаточно того, как функционал работает сейчас. > Если хранитель экрана обращается к pam_pkcs11.so, то что предполагается от него получить в данном сценарии тестирования (и почему)? Предполагается, что kscreenlocker не будет уходить в черный экран в связи с тем, что зависает его процесс в ожидании токена (или чего-то еще) Повторюсь, я пытаюсь доисследовать первопричины проблемы, но возможно правильнее будет просто закрыть баг и вернуться к нему в том случае, если он начнет воспроизводиться в более популярных сценариях. Хотелось бы знать ваше мнение по этому вопросу.
(Ответ для Белая Алёна на комментарий #26) > > Если хранитель экрана обращается к pam_pkcs11.so, то что предполагается от него получить в данном сценарии тестирования (и почему)? > Предполагается, что kscreenlocker не будет уходить в черный экран в связи с > тем, что зависает его процесс в ожидании токена (или чего-то еще) Смысл вопроса был чуть в другом: должен ли pam_pkcs11.so действительно выполнить аутентификацию в данном случае? И если да, то имеет ли он такую возможность (токен вставлен)?
(Ответ для manowar@altlinux.org на комментарий #27) > Смысл вопроса был чуть в другом: должен ли pam_pkcs11.so действительно > выполнить аутентификацию в данном случае? И если да, то имеет ли он такую > возможность (токен вставлен)? Мне сложно ответить на этот вопрос, т.к. я не знаю в точности алгоритм обращения kscreenlocker к pam_pkcs11.so, а также для себя вижу несколько вариантов развития событий. Вполне правильно, что pam_pkcs11.so ждет карту, если к нему обратился хранитель экрана, если нет никаких ошибок. Но должен ли pam_pkcs11 ждать токен, если например произошла ошибка при инициализации модуля или при загрузке данных аутентификации? Ведь в таком случае что токен вставлен, что нет, вход по нему невозможен. Или может, в этот момент kscreenlocker вообще не должен обращаться в pam_pkcs11.so и тогда проблема в kscreenlocker. И если ошибок нет, токен не вставлен, должен ли pam_pkcs11.so ждать до победного? Или правильнее, чтобы он ожидал в течение какого-то времени, а потом возвращал в хранитель экрана ответ, что у него нет возможности выполнить аутентификацию?
