При разблокировке экрана после ввода правильного пароля происходит сбой аутентификации. В лог выдаються сообщения: дек 14 13:56:15 host-135 mate-screensave[2962]: UNSPECIFIED (__progname="mate-screensaver-pam-helper" uid=500 gid=500 egid=24): pam_tcb(mate-screensaver:auth): Authentication failed for user from (uid=500) дек 14 13:56:17 host-135 mate-screensave[2962]: UNSPECIFIED (__progname="mate-screensaver-pam-helper" uid=500 gid=500 egid=24)[2962]: pam_authenticate(mate-screensaver, user): Authentication failure дек 14 13:57:19 host-135 mate-screensave[2984]: UNSPECIFIED (__progname="mate-screensaver-pam-helper" uid=500 gid=500 egid=24)[2984]: error reading reply
Наблюдается ли проблема с ядром std-def? В стартерките mate с ядрами std-def и un-def проблему воспроизвести не смог. Не установлен ли какой-нибудь light-locker?
(Ответ для Антон Мидюков на комментарий #1) > Наблюдается ли проблема с ядром std-def? В стартерките mate с ядрами std-def > и un-def проблему воспроизвести не смог. Заменил ядро на 5.10.84-std-def-alt1 и протестировал. Проблема воспроизвелась. > > Не установлен ли какой-нибудь light-locker? Нет.
Сравнил различие control со стартеркитом. В стартерките: # control |grep tcb_chkpwd tcb_chkpwd tcb (traditional tcb restricted) А в WS: # control |grep tcb_chkpwd tcb_chkpwd restricted (traditional tcb restricted) Мне помогло: # control tcb_chkpwd tcb Почему такой дефолт выставляется в этом образе WS? Какой дефолт в самой WS?
Данная проблема проявляется в образах: http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.0-aarch64.img.xz http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/aarch64/alt-workstation-10.0-aarch64.iso В последнем только при загрузке в Live. В установленной системе проблема не проявляется.
(Ответ для jqt4 на комментарий #4) > Данная проблема проявляется в образах: > http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/ > aarch64/alt-workstation-10.0-aarch64.img.xz > http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/images/workstation/ > aarch64/alt-workstation-10.0-aarch64.iso > В последнем только при загрузке в Live. В установленной системе проблема не > проявляется. Надо на рабочую станцию перевешивать. Но версии 10.0 ещё нет, так что некуда. Предполагаю, что нужно в профиль добавить: @$(call add,CONTROL,tcb_chkpwd:tcb)
Для обхода нужно переключиться на другой экран, например ctrl-alt-f2 и подать команду от root: control tcb_chkpwd tcb
В образе http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/workstation/aarch64/alt-workstation-rpi4-9.2-aarch64.tar.xz права доступа файла /usr/lib/chkpwd/tcb_chkpwd по умолчанию соответствуют состоянию после команды control tcb_chkpwd tcb В профиле, на котором был создан этот образ https://git.altlinux.org/people/jqt4/public/?p=mkimage-profiles-rpi.git;a=shortlog;h=refs/heads/alt-ws-9.2-rpi никаких действий с tcb_chkpwd не видно. На основании этого могу предположить, что проблема может быть вызвана изменением в p10, возможно, в пакете pam0_tcb, в результате которых права доступа файла /usr/lib/chkpwd/tcb_chkpwd по умолчанию изменились и стали соответствовать состоянию после команды control tcb_chkpwd restricted
(In reply to jqt4 from comment #7) > В образе > http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/workstation/ > aarch64/alt-workstation-rpi4-9.2-aarch64.tar.xz > права доступа файла /usr/lib/chkpwd/tcb_chkpwd по умолчанию соответствуют > состоянию после команды > control tcb_chkpwd tcb > > В профиле, на котором был создан этот образ > https://git.altlinux.org/people/jqt4/public/?p=mkimage-profiles-rpi.git; > a=shortlog;h=refs/heads/alt-ws-9.2-rpi > никаких действий с tcb_chkpwd не видно. > > На основании этого могу предположить, что проблема может быть вызвана > изменением в p10, возможно, в пакете pam0_tcb, в результате которых права > доступа файла /usr/lib/chkpwd/tcb_chkpwd > по умолчанию изменились и стали соответствовать состоянию после команды > control tcb_chkpwd restricted В пакете pam0_tcb всё правильно, кроме того, там ничего не менялось. Проблема где-то на стадии изготовления образов. Более того, проблема, возможно, не только с этим файлом.
Проблема оказалась в неправильной инициализации сборочного chroot. В mkimage-profiles пакет branding-<BRANDING_NAME>-release явно прописывается в число пакетов инициализируемого chroot. Сделано было так для того, чтобы в chroot был правильный брендинг. Фича pkgpriorities в mkimage-profiles с этой задачей справиться не может. Проблем не было до тех пор, пока у пакетов branding-<BRANDING_NAME>-release не было зависимостей. Теперь же, когда пакеты имеют зависимость на alt-os-release, это приводит к неправильной инициализации chroot, и как следствие к неправильному выставлению прав на некоторые файлы. Решением проблемы является исключение из инициализируемого chroot пакета branding-<BRANDING_NAME>-release и добавление этого пакета в список пакетов второй очереди PACKAGES_REQUIRED_INITROOT. Т.е. устанавливать его вместе с пакетом basesystem, чтобы тот не вытягивал неправильный брендинг в chroot. Исправление: https://git.altlinux.org/people/antohami/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=8551e71028f639601376fb779f5ff63218f3d3b0
Исправлено в [#292368] p10 DONE mkimage-profiles.git=1.4.23-alt1
