Необходим более удобный интерфейс для замены пароля в случае его устаревания. 1. Свести все диалоги ввода на одно пространство. 2. Сразу выполнять (или настроить) индикацию политики сложности пароля (информацию брать из домена или локально из файла конфигурации). При сбое не повторять все шаги заново. 3. Добавить полноценную локализацию сообщений.
Андрей, что означают загадочные слова про "одно пространство"?
(Ответ для manowar@altlinux.org на комментарий #1) > Андрей, что означают загадочные слова про "одно пространство"? В одном окне одновременно.
Теперь понял. А есть хотя бы примерное представление о том, как можно это реализовать? Для этого нужно как-то предсказывать, какие запросы будут поступать от ОС в процессе аутентификации.
(Ответ для manowar@altlinux.org на комментарий #3) > Теперь понял. > > А есть хотя бы примерное представление о том, как можно это реализовать? Для > этого нужно как-то предсказывать, какие запросы будут поступать от ОС в > процессе аутентификации. Верно. Может, вообще сделать глубоко переработанный greeter?
Мне кажется не обоснованно сложным перерабатывать гритер, в то время как вся остальная часть операционной системы, которая работает до гритера, построена по совершенно другой логике. Это будет борьба со следствием, а не с причиной. Вот тебе пример. Допустим, у пользователя A криво отображается сайт S. Мы выясняем, что сайт S действительно содержит ошибку, но исправить сайт мы, понятное дело, не можем. Однако, мы можем добавить в браузер нашлёпку, которая исправит отображение. Сделать это возможно, но мудрым и технологичным такое "решение" не назовёшь: оно получится одновременно и сложным и очень хрупким. Я согласен добавить в гритер поддержку num_msg > 1. Но только после того, как у нас появится модуль, который будет отправлять в pam_conv() такие сгруппированные запросы. Тогда пишем в pam.d/lightdm нужную опцию или как-то ещё сообщаем модулю, что мы умеем num_msg > 1 и будет всё целыми диалогами, как ты хочешь.
Глубоко переработанный sddm уже есть и именно поэтому мы от него отказались. Надо идти с архитектуры и смотреть что передаёт PAM, а если этих данных недостаточно - думать как их добавить.
Не достаточно. PAM передаёт по 1 сообщению за раз, хотя гипотетически, мог бы весь очередной диалог стазу передавать. Тогда num_msg обрело бы какой-то смысл. Антон прав, без изменения самой логики аутентификации эту проблему не решить. То есть, нужна не глубокая переработка гритера, как сказал Андрей, но переработка _в глубине_ системы. Возможно, не слишком большая.
