Bug 28277 - Нельзя снять блокировку экрана e17
Summary: Нельзя снять блокировку экрана e17
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: e17 (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Yuri N. Sedunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 27685
  Show dependency tree
 
Reported: 2012-12-26 13:11 MSK by AEN
Modified: 2013-04-09 21:07 MSK (History)
7 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description AEN 2012-12-26 13:11:13 MSK
После включения блокировки из нее удается выйти, сообщается о неверном пароле. Этот эффект сейчас только для e17.
Comment 1 AEN 2012-12-26 13:15:00 MSK
(В ответ на комментарий №0)
> После включения блокировки из нее удается выйти, сообщается о неверном пароле.
> Этот эффект сейчас только для e17.

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

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

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

Я вижу два варианта:
1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_ остальные скринсейверы из Сизифа уже работают с ним.  
2. Изменить умолчания.
Comment 5 Yuri N. Sedunov 2012-12-28 22:43:02 MSK
(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 AEN 2012-12-29 02:55:15 MSK
(В ответ на комментарий №5)

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

Да, спасибо, это важно. https://bugzilla.altlinux.org/show_bug.cgi?id=28291
Comment 7 manowar@altlinux.org 2013-02-01 01:09:14 MSK
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 manowar@altlinux.org 2013-02-11 14:41:18 MSK
При попытке обратиться к 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 manowar@altlinux.org 2013-02-13 13:07:49 MSK
Обобщённая формулировка текущей проблемы: проверка пароля в Альт требует дополнительных привилегий для программы, но никакие дополнительные привилегии не совместимы с libdbus.
Comment 10 manowar@altlinux.org 2013-02-13 16:59:22 MSK
  Сейчас подумал, что самым корректным способом обойти эту проблему было бы добавить в 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 manowar@altlinux.org 2013-02-14 02:54:46 MSK
Created attachment 5736 [details]
Добавляет в libdbus функцию для явного указания адреса шины


  Я нарисовал такой патч к libdbus: наверное простой функции для задания адреса будет достаточно?
Comment 12 manowar@altlinux.org 2013-02-14 02:59:07 MSK
Created attachment 5737 [details]
Явно выставляет адрес шины


  Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить проверку на то, чтобы адрес был сокетом.
Comment 13 Dmitry V. Levin 2013-02-14 04:38:28 MSK
(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 Dmitry V. Levin 2013-02-14 04:41:15 MSK
(In reply to comment #12)
> Created an attachment (id=5737) [details]
> Явно выставляет адрес шины
> 
> 
>   Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить
> проверку на то, чтобы адрес был сокетом.

Фактически, это будет дублированием кода из libdbus?
Comment 15 manowar@altlinux.org 2013-02-14 12:55:24 MSK
(В ответ на комментарий №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 Dmitry V. Levin 2013-02-14 13:01:37 MSK
(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 manowar@altlinux.org 2013-02-14 13:25:47 MSK
  OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, что они мне ответят на этот раз.
Comment 18 Dmitry V. Levin 2013-02-14 13:32:18 MSK
(In reply to comment #17)
>   OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим,
> что они мне ответят на этот раз.

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

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

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


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

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

Если есть возможность пойти другим путем и не делать весь e17 привилегированным, то почему мы еще не пошли этим путем?  С другой стороны, если e17, не будучи привилегированным, сможет проверять пароль, то что помешает кому попало делать то же самое?
Comment 25 manowar@altlinux.org 2013-02-14 20:47:41 MSK
(В ответ на комментарий №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 manowar@altlinux.org 2013-02-14 21:28:03 MSK
  Насколько я сумел разобраться, 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 manowar@altlinux.org 2013-02-15 13:58:05 MSK
(В ответ на комментарий №25)
> > >   Может быть мы пойдём другим путём? :)
> > 
> > Если есть возможность пойти другим путем и не делать весь e17
> > привилегированным, то почему мы еще не пошли этим путем?
> 
>   Так его нужно сперва найти, этот путь. ;)

  А существует ли надёжный способ опознать программу на другом конце stdin? Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться проверять пароль только если он 1) получает stdin от родителя; 2) этим родителем является /usr/bin/enlightenment.
Comment 28 Dmitry V. Levin 2013-02-15 14:14:42 MSK
(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 manowar@altlinux.org 2013-02-15 14:27:50 MSK
(В ответ на комментарий №28)

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

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

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

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

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

pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что угодно.
Например, если используется авторизация смарт-картой, то это будет совсем другой пароль, проверяемый без участия tcb_chkpwd.
То, что
Comment 33 manowar@altlinux.org 2013-02-15 16:16:46 MSK
(В ответ на комментарий №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 led 2013-04-03 01:12:38 MSK
Created attachment 5796 [details]
Поддержка PAM-хелпера

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

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

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

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

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

Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP 2710", где $GROUP равен, например xgrp?
Comment 40 Dmitry V. Levin 2013-04-03 03:35:28 MSK
(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 led 2013-04-03 03:51:20 MSK
(В ответ на комментарий №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 AEN 2013-04-03 04:51:55 MSK
В тестовой сборке 93678 блокировка успешно снимается.
Comment 43 Anton Farygin 2013-04-03 09:43:41 MSK
в P6 тоже отправьте, пожалуйста.
Comment 44 Repository Robot 2013-04-03 21:09:40 MSK
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 Michael Shigorin 2013-04-09 20:32:22 MSK
Эээ... у меня пока не получается подтвердить, что исправлено; на своём ноутбуке с 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 Michael Shigorin 2013-04-09 20:51:52 MSK
Ой.  При попытке показать ldv@ удалось зайти как со своим, так и с заведомо неправильным паролем, при этом в /var/log/auth/all и на tty12 никаких сообщений от pam не поступило (точно помню, что при предыдущей проверке pam.*enlightenment было).
Comment 47 Michael Shigorin 2013-04-09 20:55:24 MSK
(В ответ на комментарий №46)
> pam.*enlightenment
Точнее, хелпер.  Хотя надо бы перепроверить, вопрос -- как...
Comment 48 led 2013-04-09 21:07:52 MSK
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