Bug 28277 - Нельзя снять блокировку экрана e17
: Нельзя снять блокировку экрана e17
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/e17)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
: 27685
  Show dependency tree
 
Reported: 2012-12-26 13:11 by
Modified: 2013-04-09 21:07 (History)


Attachments
Добавляет в libdbus функцию для явного указания адреса шины (1.87 KB, patch)
2013-02-14 02:54, manowar@altlinux.org
no flags Details | Diff
Явно выставляет адрес шины (782 bytes, patch)
2013-02-14 02:59, manowar@altlinux.org
no flags Details | Diff
Поддержка PAM-хелпера (2.05 KB, patch)
2013-04-03 01:12, led@altlinux.org
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-12-26 13:11:13
После включения блокировки из нее удается выйти, сообщается о неверном пароле.
Этот эффект сейчас только для e17.
------- Comment #1 From 2012-12-26 13:15:00 -------
(В ответ на комментарий №0)
> После включения блокировки из нее удается выйти, сообщается о неверном пароле.
> Этот эффект сейчас только для e17.

не удается, конечно
------- Comment #2 From 2012-12-28 21:43:33 -------
workaround.
Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock
для блокировки экрана, получим работающую блокировку. 
Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он
вызывается. 

Бага остается открытой, но major->normal .
------- Comment #3 From 2012-12-28 22:19:31 -------
(In reply to comment #2)
> workaround.
> Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock
> для блокировки экрана, получим работающую блокировку. 
> Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он
> вызывается. 

Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не
работает.
------- Comment #4 From 2012-12-28 22:24:45 -------
(В ответ на комментарий №3)
> (In reply to comment #2)
> > workaround.
> > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock
> > для блокировки экрана, получим работающую блокировку. 
> > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он
> > вызывается. 
> 
> Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не
> работает.

Я вижу два варианта:
1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_
остальные скринсейверы из Сизифа уже работают с ним.  
2. Изменить умолчания.
------- Comment #5 From 2012-12-28 22:43:02 -------
(In reply to comment #4)
> (В ответ на комментарий №3)
> > (In reply to comment #2)
> > > workaround.
> > > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock
> > > для блокировки экрана, получим работающую блокировку. 
> > > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он
> > > вызывается. 
> > 
> > Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не
> > работает.
> 
> Я вижу два варианта:
> 1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_
> остальные скринсейверы из Сизифа уже работают с ним.  
> 2. Изменить умолчания.

Со временем, что-нибудь сделается. Попутно еще надо разобраться с тремя
суидными бинарниками в составе e17, с помощью которых он выполняет системные
действия.
------- Comment #6 From 2012-12-29 02:55:15 -------
(В ответ на комментарий №5)

> Попутно еще надо разобраться с тремя
> суидными бинарниками в составе e17, с помощью которых он выполняет системные
> действия.

Да, спасибо, это важно. https://bugzilla.altlinux.org/show_bug.cgi?id=28291
------- Comment #7 From 2013-02-01 01:09:14 -------
29.01.2013 20:58, Dmitry V. Levin пишет:

>>> > > 434	               ptrace(PT_TRACE_ME, 0, NULL, NULL);
> Занавес.
> 
> Попробуй запускать enlightenment_start с ключом 
> -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it

---

  Есть идея запускать enlightenment_start без всяких опций, но пропускать
выполнение ptrace в том случае, если на /usr/bin/enlightenment установлен
setgid-бит.
------- Comment #8 From 2013-02-11 14:41:18 -------
При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when
setuid". Видимо, это вот этот коммит:

http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d

Мне он не нравится хотя бы потому, что одновременно запрещает использовать
адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину
(autolaunch). Получается, что setuid/setgid программы вообще не могут
использовать dbus.
------- Comment #9 From 2013-02-13 13:07:49 -------
Обобщённая формулировка текущей проблемы: проверка пароля в Альт требует
дополнительных привилегий для программы, но никакие дополнительные привилегии
не совместимы с libdbus.
------- Comment #10 From 2013-02-13 16:59:22 -------
  Сейчас подумал, что самым корректным способом обойти эту проблему было бы
добавить в libdbus возможность явным образом задать адрес для соединения, т.е.
содержимое bus_connection_addresses[i]. Тогда привилегированная программа могла
бы прописать туда доверенный адрес, выполнив перед этим все необходимые
проверки.
  И зацепка такая есть:

      /* So it's not in the environment - let's try a platform-specific method.
       * On MacOS, this involves asking launchd.  On Windows (not specified
yet)
       * we might do a COM lookup.
       * Ignore errors - if we failed, fall back to autolaunch. */
      retval = _dbus_lookup_session_address (&supported, &addr, &error);

  Можно попробовать добавить такой "platform-specific method" для нашей
расчудесной платформы. :)
------- Comment #11 From 2013-02-14 02:54:46 -------
Created an attachment (id=5736) [details]
Добавляет в libdbus функцию для явного указания адреса шины


  Я нарисовал такой патч к libdbus: наверное простой функции для задания адреса
будет достаточно?
------- Comment #12 From 2013-02-14 02:59:07 -------
Created an attachment (id=5737) [details]
Явно выставляет адрес шины


  Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить
проверку на то, чтобы адрес был сокетом.
------- Comment #13 From 2013-02-14 04:38:28 -------
(In reply to comment #8)
> При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when
> setuid". Видимо, это вот этот коммит:
> 
> http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d
> 
> Мне он не нравится хотя бы потому, что одновременно запрещает использовать
> адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину
> (autolaunch). Получается, что setuid/setgid программы вообще не могут
> использовать dbus.

Я считаю, что проверка в libdbus неоправданно жесткая.  Cуть
_dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс
настолько привилегированным, чтобы это давало возможность использовать libdbus
таким образом, чтобы добиться чего-то недоступного обычному процессу.  Я не
вижу, каким образом значение saved set-group-ID может повлиять на поведение
libdbus, следовательно, проверка saved set-group-ID не нужна.
------- Comment #14 From 2013-02-14 04:41:15 -------
(In reply to comment #12)
> Created an attachment (id=5737) [details] [details]
> Явно выставляет адрес шины
> 
> 
>   Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить
> проверку на то, чтобы адрес был сокетом.

Фактически, это будет дублированием кода из libdbus?
------- Comment #15 From 2013-02-14 12:55:24 -------
(В ответ на комментарий №13)
> (In reply to comment #8)
> > При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when
> > setuid". Видимо, это вот этот коммит:
> > 
> > http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d
> > 
> > Мне он не нравится хотя бы потому, что одновременно запрещает использовать
> > адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину
> > (autolaunch). Получается, что setuid/setgid программы вообще не могут
> > использовать dbus.
> 
> Я считаю, что проверка в libdbus неоправданно жесткая.  Cуть
> _dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс
> настолько привилегированным, чтобы это давало возможность использовать libdbus
> таким образом, чтобы добиться чего-то недоступного обычному процессу.  Я не
> вижу, каким образом значение saved set-group-ID может повлиять на поведение
> libdbus, следовательно, проверка saved set-group-ID не нужна.

  А saved set-user-ID ?
------- Comment #16 From 2013-02-14 13:01:37 -------
(In reply to comment #15)
> (В ответ на комментарий №13)
> > (In reply to comment #8)
> > > При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when
> > > setuid". Видимо, это вот этот коммит:
> > > 
> > > http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d
> > > 
> > > Мне он не нравится хотя бы потому, что одновременно запрещает использовать
> > > адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину
> > > (autolaunch). Получается, что setuid/setgid программы вообще не могут
> > > использовать dbus.
> > 
> > Я считаю, что проверка в libdbus неоправданно жесткая.  Cуть
> > _dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс
> > настолько привилегированным, чтобы это давало возможность использовать libdbus
> > таким образом, чтобы добиться чего-то недоступного обычному процессу.  Я не
> > вижу, каким образом значение saved set-group-ID может повлиять на поведение
> > libdbus, следовательно, проверка saved set-group-ID не нужна.
> 
>   А saved set-user-ID ?

Тоже не нужна, в принципе, но у нас таких приложений нет.
------- Comment #17 From 2013-02-14 13:25:47 -------
  OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим,
что они мне ответят на этот раз.
------- Comment #18 From 2013-02-14 13:32:18 -------
(In reply to comment #17)
>   OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим,
> что они мне ответят на этот раз.

fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git
------- Comment #19 From 2013-02-14 13:37:14 -------
(В ответ на комментарий №18)
> (In reply to comment #17)
> >   OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим,
> > что они мне ответят на этот раз.
> 
> fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git

  Ага. Подожди собирать: апстрим вроде бы идёт на контакт — пусть посмотрят.
------- Comment #20 From 2013-02-14 14:07:47 -------
https://bugs.freedesktop.org/show_bug.cgi?id=60667
------- Comment #21 From 2013-02-14 17:19:38 -------
  Дима, с freedesktop'а ответили. Посмотри, пожалуйста.
------- Comment #22 From 2013-02-14 18:21:22 -------
И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже
важное замечание:

https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7


  Может быть мы пойдём другим путём? :)
------- Comment #23 From 2013-02-14 18:27:53 -------
... GNOME 3 in non-fallback mode integrates the screensaver into GNOME Shell
rather than using an external gnome-screensaver...

  А вот это уже очень интересно, поскольку в gnome3 залочка снимается без
проблем. Выходит, есть способ.
------- Comment #24 From 2013-02-14 18:50:37 -------
(In reply to comment #22)
> И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже
> важное замечание:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7
> 
> 
>   Может быть мы пойдём другим путём? :)

Если есть возможность пойти другим путем и не делать весь e17
привилегированным, то почему мы еще не пошли этим путем?  С другой стороны,
если e17, не будучи привилегированным, сможет проверять пароль, то что помешает
кому попало делать то же самое?
------- Comment #25 From 2013-02-14 20:47:41 -------
(В ответ на комментарий №24)
> (In reply to comment #22)
> > И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже
> > важное замечание:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7
> > 
> > 
> >   Может быть мы пойдём другим путём? :)
> 
> Если есть возможность пойти другим путем и не делать весь e17
> привилегированным, то почему мы еще не пошли этим путем?

  Так его нужно сперва найти, этот путь. ;)

  В одном Саймон, кажется, прав: пользователь может легко написать модуль
взлома пароля и подключить его к e17. Нельзя ставить динамически расширяемым
программам suid/sgid. :(

> С другой стороны, если e17, не будучи привилегированным, сможет проверять
> пароль, то что помешает кому попало делать то же самое?

  Нужно пристально взглянуть как это происходит в GNOME Shell. Потому как там:
а) локер выглядит интегрированным, б) он проверяет успешно пароль.
------- Comment #26 From 2013-02-14 21:28:03 -------
  Насколько я сумел разобраться, gnome-shell использует интерфейс
Gdm.UserVerifier [1] для проверки пароля, причём как в хранителе экрана, так и
в окне входа в систему (последнее теперь тоже отображается через gnome-shell).
Однако как в точности всё это работает и может ли обычный
пользователь/программа воспользоваться этим сервисом я пока не понял.

---
[1] http://www.roojs.org/seed/gir-1.2-gtk-3.0/seed/Gdm.UserVerifier.html
------- Comment #27 From 2013-02-15 13:58:05 -------
(В ответ на комментарий №25)
> > >   Может быть мы пойдём другим путём? :)
> > 
> > Если есть возможность пойти другим путем и не делать весь e17
> > привилегированным, то почему мы еще не пошли этим путем?
> 
>   Так его нужно сперва найти, этот путь. ;)

  А существует ли надёжный способ опознать программу на другом конце stdin?
Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться
проверять пароль только если он 1) получает stdin от родителя; 2) этим
родителем является /usr/bin/enlightenment.
------- Comment #28 From 2013-02-15 14:14:42 -------
(In reply to comment #27)
> (В ответ на комментарий №25)
> > > >   Может быть мы пойдём другим путём? :)
> > > 
> > > Если есть возможность пойти другим путем и не делать весь e17
> > > привилегированным, то почему мы еще не пошли этим путем?
> > 
> >   Так его нужно сперва найти, этот путь. ;)
> 
>   А существует ли надёжный способ опознать программу на другом конце stdin?

Если это AF_UNIX socket, то можно узнать pid и euid процесса, создавшего этот
сокет, и сравнить с parent'ом.  Зная $pid, можно смотреть на /proc/$pid/exe и
/proc/$pid/cmdline.
См. напр.
http://git.altlinux.org/people/ldv/packages/?p=openssh.git;a=blob;f=openssh/openbsd-compat/getpeerproc.c

Но у tcb_chkpwd stdin не socket а pipe.

> Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться
> проверять пароль только если он 1) получает stdin от родителя; 2) этим
> родителем является /usr/bin/enlightenment.

Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment.
------- Comment #29 From 2013-02-15 14:27:50 -------
(В ответ на комментарий №28)

> > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться
> > проверять пароль только если он 1) получает stdin от родителя; 2) этим
> > родителем является /usr/bin/enlightenment.
> 
> Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment.

  Совсем не хочется выпиливать весь desklock хотя бы потому, что у
интегрированного потенциально появляется больше интересных для пользователя
возможностей, не говоря уже об огромном разломе с апстримом, который появится в
результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой
либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не
сделать хелпер "для всех".
------- Comment #30 From 2013-02-15 14:35:12 -------
(In reply to comment #29)
> (В ответ на комментарий №28)
> 
> > > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться
> > > проверять пароль только если он 1) получает stdin от родителя; 2) этим
> > > родителем является /usr/bin/enlightenment.
> > 
> > Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment.
> 
>   Совсем не хочется выпиливать весь desklock хотя бы потому, что у
> интегрированного потенциально появляется больше интересных для пользователя
> возможностей, не говоря уже об огромном разломе с апстримом, который появится в
> результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой
> либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не
> сделать хелпер "для всех".

Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он
спросит у пользователя во время работы?
------- Comment #31 From 2013-02-15 14:44:27 -------
(В ответ на комментарий №30)

> Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он
> спросит у пользователя во время работы?

  Так из входных данных у меня только пароль. Соответственно только его и
скармливаю в хелпер. Остальное хелпер должен сделать сам и ответить мне,
снимать блокировку экрана или нет.
------- Comment #32 From 2013-02-15 15:45:27 -------
(In reply to comment #31)
> (В ответ на комментарий №30)
> 
> > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он
> > спросит у пользователя во время работы?
> 
>   Так из входных данных у меня только пароль.

pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что
угодно.
Например, если используется авторизация смарт-картой, то это будет совсем
другой пароль, проверяемый без участия tcb_chkpwd.
То, что
------- Comment #33 From 2013-02-15 16:16:46 -------
(В ответ на комментарий №32)
> (In reply to comment #31)
> > (В ответ на комментарий №30)
> > 
> > > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он
> > > спросит у пользователя во время работы?
> > 
> >   Так из входных данных у меня только пароль.
> 
> pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что
> угодно.

  Судя по _desklock_auth_pam_conv() [1] e17 умеет отвечать только заранее
заготовленными именем пользователя и паролем. Передавать пользователю
интерактивно какие-то специфичные вопросы от PAM он не умеет.

---
[1]
http://git.altlinux.org/people/manowar/packages/e17.git?p=e17.git;a=blob;f=enlightenment/src/bin/e_desklock.c;h=f28179039ee82e69c092020abb24a921f578794d;hb=0e845b49daf4e118e50134e70a0e760b58c0069f#l1123
------- Comment #34 From 2013-04-03 01:12:38 -------
Created an attachment (id=5796) [details]
Поддержка PAM-хелпера

Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с
помощью хелпера chkpwd-pam.
При сборке неоходимо добавит ключ для %configure
--with-pam-helper=/usr/libexec/chkpwd-pam
------- Comment #35 From 2013-04-03 01:24:17 -------
(В ответ на комментарий №34)
> Created an attachment (id=5796) [details] [details]
> Поддержка PAM-хелпера
> 
> Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с
> помощью хелпера chkpwd-pam.
> При сборке неоходимо добавит ключ для %configure
> --with-pam-helper=/usr/libexec/chkpwd-pam

О!
2led@: Спасибо! А можно собрать такой e17 test-only?
2aris@: прошу содействия, в частности хорошо бы проверить для e18 (не срочно,
но важно).
------- Comment #36 From 2013-04-03 01:26:55 -------
(В ответ на комментарий №34)
> Created an attachment (id=5796) [details] [details]
> Поддержка PAM-хелпера
> 
> Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с
> помощью хелпера chkpwd-pam.
2all: Вот он в Сизифе:
http://packages.altlinux.org/en/Sisyphus/srpms/chkpwd-pam
------- Comment #37 From 2013-04-03 01:37:33 -------
  Может быть я что-то упустил в пакете chkpwd-pam, но когда я обсуждал с ldv@
возможность такого решения, то он ответил, что проще просто убрать требование
наличия группы chkpwd, чем использовать доступный пользователю хелпер.

  Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе,
мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и
заниматься подбором пароля?
------- Comment #38 From 2013-04-03 01:51:35 -------
(In reply to comment #37)
>   Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе,
> мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и
> заниматься подбором пароля?

Предполагается встроить в chkpwd-pam средства, ограничивающие доступ и
затрудняющие подбор.

Давайте, пока не поздно, поменяем
/usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam.
------- Comment #39 From 2013-04-03 02:59:05 -------
(В ответ на комментарий №38)
> Давайте, пока не поздно, поменяем
> /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam.

Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP
2710", где $GROUP равен, например xgrp?
------- Comment #40 From 2013-04-03 03:35:28 -------
(In reply to comment #39)
> (В ответ на комментарий №38)
> > Давайте, пока не поздно, поменяем
> > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam.
> 
> Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP
> 2710", где $GROUP равен, например xgrp?

Да, для будущего ограничения доступа, не обязательно xgrp.
------- Comment #41 From 2013-04-03 03:51:20 -------
(В ответ на комментарий №40)
> (In reply to comment #39)
> > (В ответ на комментарий №38)
> > > Давайте, пока не поздно, поменяем
> > > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam.
> > 
> > Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP
> > 2710", где $GROUP равен, например xgrp?
> 
> Да, для будущего ограничения доступа, не обязательно xgrp.

Сделано в chkpwd-pam-0.1.0-alt2: /usr/libexec/chkpwd-pam/chkpwd-pam
------- Comment #42 From 2013-04-03 04:51:55 -------
В тестовой сборке 93678 блокировка успешно снимается.
------- Comment #43 From 2013-04-03 09:43:41 -------
в P6 тоже отправьте, пожалуйста.
------- Comment #44 From 2013-04-03 21:09:40 -------
e17-1:0.17.1-alt2 -> sisyphus:

* Wed Apr 03 2013 Led <led@altlinux> 1:0.17.1-alt2
- with pam helper (ALT#28277)
------- Comment #45 From 2013-04-09 20:32:22 -------
Эээ... у меня пока не получается подтвердить, что исправлено; на своём ноутбуке
с 1:0.17.1-alt2 и на
http://nightly.altlinux.org/sisyphus/snapshots/20130409/regular-e17-20130409-i586.iso
с 1:0.17.1-alt3 зайти после блокирования экрана встроенным локером не
получается (номер для SMS при этом не предлагает).
------- Comment #46 From 2013-04-09 20:51:52 -------
Ой.  При попытке показать ldv@ удалось зайти как со своим, так и с заведомо
неправильным паролем, при этом в /var/log/auth/all и на tty12 никаких сообщений
от pam не поступило (точно помню, что при предыдущей проверке
pam.*enlightenment было).
------- Comment #47 From 2013-04-09 20:55:24 -------
(В ответ на комментарий №46)
> pam.*enlightenment
Точнее, хелпер.  Хотя надо бы перепроверить, вопрос -- как...
------- Comment #48 From 2013-04-09 21:07:52 -------
chkpwd-pam-0.1.1.1-alt1

* Tue Apr 09 2013 Led <led@altlinux.ru> 0.1.1.1-alt1
- chkpwd-pam.c: fixed lockdir path