28277 2012-12-26 13:11:13 +0400 Нельзя снять блокировку экрана e17 2013-04-09 21:07:52 +0400 1 1 4 Development Sisyphus e17 unstable all Linux CLOSED FIXED P3 normal --- 27685 1 aen aris ldv led manowar mike rider sbolshakov vladimir.didenko qa-sisyphus oldest_to_newest 136407 0 aen 2012-12-26 13:11:13 +0400 После включения блокировки из нее удается выйти, сообщается о неверном пароле. Этот эффект сейчас только для e17. 136409 1 aen 2012-12-26 13:15:00 +0400 (В ответ на комментарий №0) > После включения блокировки из нее удается выйти, сообщается о неверном пароле. > Этот эффект сейчас только для e17. не удается, конечно 136507 2 aen 2012-12-28 21:43:33 +0400 workaround. Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock для блокировки экрана, получим работающую блокировку. Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он вызывается. Бага остается открытой, но major->normal . 136508 3 aris 2012-12-28 22:19:31 +0400 (In reply to comment #2) > workaround. > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock > для блокировки экрана, получим работающую блокировку. > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он > вызывается. Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не работает. 136509 4 aen 2012-12-28 22:24:45 +0400 (В ответ на комментарий №3) > (In reply to comment #2) > > workaround. > > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock > > для блокировки экрана, получим работающую блокировку. > > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он > > вызывается. > > Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не > работает. Я вижу два варианта: 1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_ остальные скринсейверы из Сизифа уже работают с ним. 2. Изменить умолчания. 136510 5 aris 2012-12-28 22:43:02 +0400 (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, с помощью которых он выполняет системные действия. 136512 6 aen 2012-12-29 02:55:15 +0400 (В ответ на комментарий №5) > Попутно еще надо разобраться с тремя > суидными бинарниками в составе e17, с помощью которых он выполняет системные > действия. Да, спасибо, это важно. https://bugzilla.altlinux.org/show_bug.cgi?id=28291 137495 7 manowar 2013-02-01 01:09:14 +0400 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-бит. 137769 8 manowar 2013-02-11 14:41:18 +0400 При попытке обратиться к 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. 137844 9 manowar 2013-02-13 13:07:49 +0400 Обобщённая формулировка текущей проблемы: проверка пароля в Альт требует дополнительных привилегий для программы, но никакие дополнительные привилегии не совместимы с libdbus. 137853 10 manowar 2013-02-13 16:59:22 +0400 Сейчас подумал, что самым корректным способом обойти эту проблему было бы добавить в 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" для нашей расчудесной платформы. :) 137867 11 5736 manowar 2013-02-14 02:54:46 +0400 Created attachment 5736 Добавляет в libdbus функцию для явного указания адреса шины Я нарисовал такой патч к libdbus: наверное простой функции для задания адреса будет достаточно? 137868 12 5737 manowar 2013-02-14 02:59:07 +0400 Created attachment 5737 Явно выставляет адрес шины Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить проверку на то, чтобы адрес был сокетом. 137869 13 ldv 2013-02-14 04:38:28 +0400 (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 не нужна. 137870 14 ldv 2013-02-14 04:41:15 +0400 (In reply to comment #12) > Created an attachment (id=5737) [details] > Явно выставляет адрес шины > > > Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить > проверку на то, чтобы адрес был сокетом. Фактически, это будет дублированием кода из libdbus? 137873 15 manowar 2013-02-14 12:55:24 +0400 (В ответ на комментарий №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 ? 137874 16 ldv 2013-02-14 13:01:37 +0400 (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 ? Тоже не нужна, в принципе, но у нас таких приложений нет. 137875 17 manowar 2013-02-14 13:25:47 +0400 OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, что они мне ответят на этот раз. 137876 18 ldv 2013-02-14 13:32:18 +0400 (In reply to comment #17) > OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, > что они мне ответят на этот раз. fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git 137878 19 manowar 2013-02-14 13:37:14 +0400 (В ответ на комментарий №18) > (In reply to comment #17) > > OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, > > что они мне ответят на этот раз. > > fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git Ага. Подожди собирать: апстрим вроде бы идёт на контакт — пусть посмотрят. 137882 20 manowar 2013-02-14 14:07:47 +0400 https://bugs.freedesktop.org/show_bug.cgi?id=60667 137905 21 manowar 2013-02-14 17:19:38 +0400 Дима, с freedesktop'а ответили. Посмотри, пожалуйста. 137909 22 manowar 2013-02-14 18:21:22 +0400 И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже важное замечание: https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7 Может быть мы пойдём другим путём? :) 137910 23 manowar 2013-02-14 18:27:53 +0400 ... GNOME 3 in non-fallback mode integrates the screensaver into GNOME Shell rather than using an external gnome-screensaver... А вот это уже очень интересно, поскольку в gnome3 залочка снимается без проблем. Выходит, есть способ. 137911 24 ldv 2013-02-14 18:50:37 +0400 (In reply to comment #22) > И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже > важное замечание: > > https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7 > > > Может быть мы пойдём другим путём? :) Если есть возможность пойти другим путем и не делать весь e17 привилегированным, то почему мы еще не пошли этим путем? С другой стороны, если e17, не будучи привилегированным, сможет проверять пароль, то что помешает кому попало делать то же самое? 137916 25 manowar 2013-02-14 20:47:41 +0400 (В ответ на комментарий №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. Потому как там: а) локер выглядит интегрированным, б) он проверяет успешно пароль. 137918 26 manowar 2013-02-14 21:28:03 +0400 Насколько я сумел разобраться, gnome-shell использует интерфейс Gdm.UserVerifier [1] для проверки пароля, причём как в хранителе экрана, так и в окне входа в систему (последнее теперь тоже отображается через gnome-shell). Однако как в точности всё это работает и может ли обычный пользователь/программа воспользоваться этим сервисом я пока не понял. --- [1] http://www.roojs.org/seed/gir-1.2-gtk-3.0/seed/Gdm.UserVerifier.html 137924 27 manowar 2013-02-15 13:58:05 +0400 (В ответ на комментарий №25) > > > Может быть мы пойдём другим путём? :) > > > > Если есть возможность пойти другим путем и не делать весь e17 > > привилегированным, то почему мы еще не пошли этим путем? > > Так его нужно сперва найти, этот путь. ;) А существует ли надёжный способ опознать программу на другом конце stdin? Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться проверять пароль только если он 1) получает stdin от родителя; 2) этим родителем является /usr/bin/enlightenment. 137928 28 ldv 2013-02-15 14:14:42 +0400 (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. 137932 29 manowar 2013-02-15 14:27:50 +0400 (В ответ на комментарий №28) > > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться > > проверять пароль только если он 1) получает stdin от родителя; 2) этим > > родителем является /usr/bin/enlightenment. > > Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment. Совсем не хочется выпиливать весь desklock хотя бы потому, что у интегрированного потенциально появляется больше интересных для пользователя возможностей, не говоря уже об огромном разломе с апстримом, который появится в результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не сделать хелпер "для всех". 137933 30 ldv 2013-02-15 14:35:12 +0400 (In reply to comment #29) > (В ответ на комментарий №28) > > > > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться > > > проверять пароль только если он 1) получает stdin от родителя; 2) этим > > > родителем является /usr/bin/enlightenment. > > > > Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment. > > Совсем не хочется выпиливать весь desklock хотя бы потому, что у > интегрированного потенциально появляется больше интересных для пользователя > возможностей, не говоря уже об огромном разломе с апстримом, который появится в > результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой > либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не > сделать хелпер "для всех". Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он спросит у пользователя во время работы? 137934 31 manowar 2013-02-15 14:44:27 +0400 (В ответ на комментарий №30) > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он > спросит у пользователя во время работы? Так из входных данных у меня только пароль. Соответственно только его и скармливаю в хелпер. Остальное хелпер должен сделать сам и ответить мне, снимать блокировку экрана или нет. 137936 32 ldv 2013-02-15 15:45:27 +0400 (In reply to comment #31) > (В ответ на комментарий №30) > > > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он > > спросит у пользователя во время работы? > > Так из входных данных у меня только пароль. pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что угодно. Например, если используется авторизация смарт-картой, то это будет совсем другой пароль, проверяемый без участия tcb_chkpwd. То, что 137938 33 manowar 2013-02-15 16:16:46 +0400 (В ответ на комментарий №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 139270 34 5796 led 2013-04-03 01:12:38 +0400 Created attachment 5796 Поддержка PAM-хелпера Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с помощью хелпера chkpwd-pam. При сборке неоходимо добавит ключ для %configure --with-pam-helper=/usr/libexec/chkpwd-pam 139273 35 aen 2013-04-03 01:24:17 +0400 (В ответ на комментарий №34) > Created an attachment (id=5796) [details] > Поддержка PAM-хелпера > > Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с > помощью хелпера chkpwd-pam. > При сборке неоходимо добавит ключ для %configure > --with-pam-helper=/usr/libexec/chkpwd-pam О! 2led@: Спасибо! А можно собрать такой e17 test-only? 2aris@: прошу содействия, в частности хорошо бы проверить для e18 (не срочно, но важно). 139274 36 aen 2013-04-03 01:26:55 +0400 (В ответ на комментарий №34) > Created an attachment (id=5796) [details] > Поддержка PAM-хелпера > > Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с > помощью хелпера chkpwd-pam. 2all: Вот он в Сизифе: http://packages.altlinux.org/en/Sisyphus/srpms/chkpwd-pam 139276 37 manowar 2013-04-03 01:37:33 +0400 Может быть я что-то упустил в пакете chkpwd-pam, но когда я обсуждал с ldv@ возможность такого решения, то он ответил, что проще просто убрать требование наличия группы chkpwd, чем использовать доступный пользователю хелпер. Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе, мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и заниматься подбором пароля? 139277 38 ldv 2013-04-03 01:51:35 +0400 (In reply to comment #37) > Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе, > мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и > заниматься подбором пароля? Предполагается встроить в chkpwd-pam средства, ограничивающие доступ и затрудняющие подбор. Давайте, пока не поздно, поменяем /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. 139278 39 led 2013-04-03 02:59:05 +0400 (В ответ на комментарий №38) > Давайте, пока не поздно, поменяем > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP 2710", где $GROUP равен, например xgrp? 139279 40 ldv 2013-04-03 03:35:28 +0400 (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. 139280 41 led 2013-04-03 03:51:20 +0400 (В ответ на комментарий №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 139282 42 aen 2013-04-03 04:51:55 +0400 В тестовой сборке 93678 блокировка успешно снимается. 139286 43 rider 2013-04-03 09:43:41 +0400 в P6 тоже отправьте, пожалуйста. 139309 44 repository-robot 2013-04-03 21:09:40 +0400 e17-1:0.17.1-alt2 -> sisyphus: * Wed Apr 03 2013 Led <led@altlinux> 1:0.17.1-alt2 - with pam helper (ALT#28277) 139472 45 mike 2013-04-09 20:32:22 +0400 Эээ... у меня пока не получается подтвердить, что исправлено; на своём ноутбуке с 1:0.17.1-alt2 и на http://nightly.altlinux.org/sisyphus/snapshots/20130409/regular-e17-20130409-i586.iso с 1:0.17.1-alt3 зайти после блокирования экрана встроенным локером не получается (номер для SMS при этом не предлагает). 139473 46 mike 2013-04-09 20:51:52 +0400 Ой. При попытке показать ldv@ удалось зайти как со своим, так и с заведомо неправильным паролем, при этом в /var/log/auth/all и на tty12 никаких сообщений от pam не поступило (точно помню, что при предыдущей проверке pam.*enlightenment было). 139475 47 mike 2013-04-09 20:55:24 +0400 (В ответ на комментарий №46) > pam.*enlightenment Точнее, хелпер. Хотя надо бы перепроверить, вопрос -- как... 139477 48 led 2013-04-09 21:07:52 +0400 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 5736 2013-02-14 02:54:46 +0400 2013-02-14 02:54:46 +0400 Добавляет в libdbus функцию для явного указания адреса шины dbus_setup_session_address.patch text/plain 1911 manowar ZGlmZiAtLWdpdCBhL2RidXMvZGJ1cy1idXMuaCBiL2RidXMvZGJ1cy1idXMuaAppbmRleCAwMmE5 NTcxLi42NTA5YjVmIDEwMDY0NAotLS0gYS9kYnVzL2RidXMtYnVzLmgKKysrIGIvZGJ1cy9kYnVz LWJ1cy5oCkBAIC04OCw2ICs4OCw5IEBAIHZvaWQgICAgICAgICAgICBkYnVzX2J1c19yZW1vdmVf bWF0Y2ggICAgIChEQnVzQ29ubmVjdGlvbiAqY29ubmVjdGlvbiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICAgICAqcnVsZSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEQnVzRXJyb3IgICAgICAqZXJyb3Ip OwogCitEQlVTX0VYUE9SVAordm9pZAkJZGJ1c19zZXR1cF9zZXNzaW9uX2FkZHJlc3MgKGNvbnN0 IGNoYXIgKmFkZHIpOworCiAvKiogQH0gKi8KIAogREJVU19FTkRfREVDTFMKZGlmZiAtLWdpdCBh L2RidXMvZGJ1cy1zeXNkZXBzLXVuaXguYyBiL2RidXMvZGJ1cy1zeXNkZXBzLXVuaXguYwppbmRl eCBiNGVjYzk2Li5kNTBkYzg0IDEwMDY0NAotLS0gYS9kYnVzL2RidXMtc3lzZGVwcy11bml4LmMK KysrIGIvZGJ1cy9kYnVzLXN5c2RlcHMtdW5peC5jCkBAIC0zNjU0LDYgKzM2NTQsMjIgQEAgX2Ri dXNfbG9va3VwX3Nlc3Npb25fYWRkcmVzc19sYXVuY2hkIChEQnVzU3RyaW5nICphZGRyZXNzLCBE QnVzRXJyb3IgICplcnJvcikKICNlbmRpZgogCiAvKioKKyAqIFNldHMgdXAgdGhlIGN1c3RvbSBz ZXNzaW9uIGJ1cyBhZGRyZXNzLgorICoKKyAqIFRoaXMgZnVuY3Rpb24gaXMgdGVuZCB0byBiZSB1 c2VkIGJ5IHNldHVpZC9zZXRnaWQKKyAqIHByb2dyYW1zIHRvIGV4cGxpY2l0bHkgc2V0IHVwIHRo ZSBkZXNpcmVkIGJ1cyBhZGRyZXNzLgorICogVG8gYXZvaWQgc2VjdXJpdHkgdmlvbGF0aW9ucyB0 aGUgYWRkcmVzcyBzaG91bGQgYmUgZmlyc3QKKyAqIGNhcmVmdWxseSBjaGVja2VkLgorICovCisK K3N0YXRpYyBjb25zdCBjaGFyICpjdXN0b21fc2Vzc2lvbl9hZGRyZXNzID0gTlVMTDsKK3ZvaWQK K2RidXNfc2V0dXBfc2Vzc2lvbl9hZGRyZXNzKGNvbnN0IGNoYXIgKmFkZHIpCit7CisgIGN1c3Rv bV9zZXNzaW9uX2FkZHJlc3MgPSBhZGRyOworfQorCisvKioKICAqIERldGVybWluZXMgdGhlIGFk ZHJlc3Mgb2YgdGhlIHNlc3Npb24gYnVzIGJ5IHF1ZXJ5aW5nIGEKICAqIHBsYXRmb3JtLXNwZWNp ZmljIG1ldGhvZC4KICAqCkBAIC0zNjgxLDExICszNjk3LDE3IEBAIF9kYnVzX2xvb2t1cF9zZXNz aW9uX2FkZHJlc3MgKGRidXNfYm9vbF90ICpzdXBwb3J0ZWQsCiAgICpzdXBwb3J0ZWQgPSBUUlVF OwogICByZXR1cm4gX2RidXNfbG9va3VwX3Nlc3Npb25fYWRkcmVzc19sYXVuY2hkIChhZGRyZXNz LCBlcnJvcik7CiAjZWxzZQotICAvKiBPbiBub24tTWFjIFVuaXggcGxhdGZvcm1zLCBpZiB0aGUg c2Vzc2lvbiBhZGRyZXNzIGlzbid0IGFscmVhZHkKLSAgICogc2V0IGluIERCVVNfU0VTU0lPTl9C VVNfQUREUkVTUyBlbnZpcm9ubWVudCB2YXJpYWJsZSwgd2UgcHVudCBhbmQKLSAgICogZmFsbCBi YWNrIHRvIHRoZSBhdXRvbGF1bmNoOiBnbG9iYWwgZGVmYXVsdDsgc2VlCi0gICAqIGluaXRfc2Vz c2lvbl9hZGRyZXNzIGluIGRidXMvZGJ1cy1idXMuYy4gKi8KLSAgKnN1cHBvcnRlZCA9IEZBTFNF OworICBpZiAoIWN1c3RvbV9zZXNzaW9uX2FkZHJlc3MpCisgICAgKnN1cHBvcnRlZCA9IEZBTFNF OworICBlbHNlCisgIHsKKyAgICAqc3VwcG9ydGVkID0gVFJVRTsKKyAgICBpZiAoIV9kYnVzX3N0 cmluZ19hcHBlbmQgKGFkZHJlc3MsIGN1c3RvbV9zZXNzaW9uX2FkZHJlc3MpKQorICAgIHsKKyAg ICAgIF9EQlVTX1NFVF9PT00gKGVycm9yKTsKKyAgICAgIHJldHVybiBGQUxTRTsKKyAgICB9Cisg IH0KICAgcmV0dXJuIFRSVUU7CiAjZW5kaWYKIH0K 5737 2013-02-14 02:59:07 +0400 2013-02-14 02:59:07 +0400 Явно выставляет адрес шины setup-session-address.patch text/plain 782 manowar ZGlmZiAtLWdpdCBhL2VubGlnaHRlbm1lbnQvc3JjL2Jpbi9lX21haW4uYyBiL2VubGlnaHRlbm1l bnQvc3JjL2Jpbi9lX21haW4uYwppbmRleCBlZThmZDhhLi44ZDhiNDRmIDEwMDY0NAotLS0gYS9l bmxpZ2h0ZW5tZW50L3NyYy9iaW4vZV9tYWluLmMKKysrIGIvZW5saWdodGVubWVudC9zcmMvYmlu L2VfbWFpbi5jCkBAIC0yNiw2ICsyNiw4IEBAIHN0YXRpYyBkb3VibGUgdDAsIHQxLCB0MjsKICNp bmNsdWRlIDxFbW90aW9uLmg+CiAjZW5kaWYKIAorI2luY2x1ZGUgPGRidXMvZGJ1cy5oPgorCiAv KgogICogaSBuZWVkIHRvIG1ha2UgbW9yZSB1c2Ugb2YgdGhlc2Ugd2hlbiBpJ20gYmFmZmxlZCBh cyB0byB3aGVuIHNvbWV0aGluZyBpcwogICogdXAuIG90aGVyIGhvb2tzOgpAQCAtMTc1LDYgKzE3 Nyw5IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogI2VuZGlmCiAKICAgIFRTKCJCZWdp biBTdGFydHVwIik7CisgICBUUygiU2V0IHVwIHRoZSBELUJ1cyBzZXNzaW9uIGFkZHJlc3MiKTsK KyAgIC8qIFRPRE86IENoZWNrIHRoZSBhZGRyZXNzIHRvIGJlIGEgc29ja2V0LiAqLworICAgZGJ1 c19zZXR1cF9zZXNzaW9uX2FkZHJlc3MoZ2V0ZW52KCJEQlVTX1NFU1NJT05fQlVTX0FERFJFU1Mi KSk7CiAKICAgIC8qIHRyYXAgZGVhZGx5IGJ1ZyBzaWduYWxzIGFuZCBhbGxvdyBzb21lIGZvcm0g b2Ygc2FuZSByZWNvdmVyeSAqLwogICAgLyogb3IgYWJpbGl0eSB0byBnZGIgYXR0YWNoIGFuZCBk ZWJ1ZyBhdCB0aGlzIHBvaW50IC0gYmV0dGVyIHRoYW4geW91ciAqLwo= 5796 2013-04-03 01:12:38 +0400 2013-04-03 01:12:38 +0400 Поддержка PAM-хелпера enlightenment-0.17.1-pam-helper.patch text/plain 2095 led ZGlmZiAtdXJOIGVubGlnaHRlbm1lbnQtMC4xNy4xL2NvbmZpZy5oLmluIGVubGlnaHRlbm1lbnQt MC4xNy4xLnBhbS9jb25maWcuaC5pbgotLS0gZW5saWdodGVubWVudC0wLjE3LjEvY29uZmlnLmgu aW4JMjAxMy0wMi0xMiAxMjoyODo0My4wMDAwMDAwMDAgKzAyMDAKKysrIGVubGlnaHRlbm1lbnQt MC4xNy4xLnBhbS9jb25maWcuaC5pbgkyMDEzLTA0LTAxIDE2OjM4OjU0LjAwMDAwMDAwMCArMDMw MApAQCAtMTE5LDYgKzExOSw5IEBACiAvKiBQQU0gQXV0aGVudGljYXRpb24gU3VwcG9ydCAqLwog I3VuZGVmIEhBVkVfUEFNCiAKKy8qIFBBTSBBdXRoZW50aWNhdGlvbiBoZWxwZXIgU3VwcG9ydCAq LworI3VuZGVmIFVTRV9QQU1fSEVMUEVSCisKIC8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo ZSA8c2VjdXJpdHkvcGFtX2FwcGwuaD4gaGVhZGVyIGZpbGUuICovCiAjdW5kZWYgSEFWRV9TRUNV UklUWV9QQU1fQVBQTF9ICiAKZGlmZiAtdXJOIGVubGlnaHRlbm1lbnQtMC4xNy4xL2NvbmZpZ3Vy ZS5hYyBlbmxpZ2h0ZW5tZW50LTAuMTcuMS5wYW0vY29uZmlndXJlLmFjCi0tLSBlbmxpZ2h0ZW5t ZW50LTAuMTcuMS9jb25maWd1cmUuYWMJMjAxMy0wMi0xMiAxMjoyODo0My4wMDAwMDAwMDAgKzAy MDAKKysrIGVubGlnaHRlbm1lbnQtMC4xNy4xLnBhbS9jb25maWd1cmUuYWMJMjAxMy0wNC0wMSAx NjozODo1NC4wMDAwMDAwMDAgKzAzMDAKQEAgLTExMSw2ICsxMTEsMTYgQEAKICAgICBmaQogZmkK IAordXNlX3BhbV9oZWxwZXI9bm8KK0FDX0FSR19XSVRIKHBhbS1oZWxwZXIsCisgIEFDX0hFTFBf U1RSSU5HKFstLXdpdGgtcGFtLWhlbHBlcl0sIFt3aXRoIFBBTSBoZWxwZXIgQDw6QGRlZmF1bHQ9 bm9AOj5AXSksCisgIFt1c2VfcGFtX2hlbHBlcj0kd2l0aHZhbF0sCisgIFt1c2VfcGFtX2hlbHBl cj1ub10KKykKK2lmIHRlc3QgIngkdXNlX3BhbV9oZWxwZXIiICE9ICJ4bm8iIDsgdGhlbgorICBB Q19ERUZJTkVfVU5RVU9URUQoVVNFX1BBTV9IRUxQRVIsICIkdXNlX3BhbV9oZWxwZXIiLCBbUEFN IEF1dGhlbnRpY2F0aW9uIGhlbHBlciBwYXRoXSkKK2ZpCisKIGRubCBBQ19FX0NIRUNLX1BLRyhW QUxHUklORCwgW3ZhbGdyaW5kID49IDIuNC4wXSwgW10sIFs6XSkKIEFDX1NVQlNUKFZBTEdSSU5E X0NGTEFHUykKIEFDX1NVQlNUKFZBTEdSSU5EX0xJQlMpCmRpZmYgLXVyTiBlbmxpZ2h0ZW5tZW50 LTAuMTcuMS9zcmMvYmluL2VfZGVza2xvY2suYyBlbmxpZ2h0ZW5tZW50LTAuMTcuMS5wYW0vc3Jj L2Jpbi9lX2Rlc2tsb2NrLmMKLS0tIGVubGlnaHRlbm1lbnQtMC4xNy4xL3NyYy9iaW4vZV9kZXNr bG9jay5jCTIwMTMtMDItMTIgMTI6Mjg6NDMuMDAwMDAwMDAwICswMjAwCisrKyBlbmxpZ2h0ZW5t ZW50LTAuMTcuMS5wYW0vc3JjL2Jpbi9lX2Rlc2tsb2NrLmMJMjAxMy0wNC0wMSAxNzoxODozNi4w MDAwMDAwMDAgKzAzMDAKQEAgLTEwMDUsNiArMTAwNSwyMiBAQAogICAgICAgICBjaGFyICpjdXJy ZW50X3VzZXIsICpwOwogICAgICAgICBzdHJ1Y3Qgc2lnYWN0aW9uIGFjdGlvbjsKIAorI2lmZGVm IFVTRV9QQU1fSEVMUEVSCisgICAgICAgIGlmICghYWNjZXNzKFVTRV9QQU1fSEVMUEVSLCBYX09L KSkgeworICAgICAgICAgIEZJTEUgKmZwID0gcG9wZW4oVVNFX1BBTV9IRUxQRVIsICJ3Iik7CisK KyAgICAgICAgICBpZiAoZnApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICBpbnQgc3Rh dHVzOworCisgICAgICAgICAgICAgICBmcHV0cyhwYXNzd2QsIGZwKTsKKyAgICAgICAgICAgICAg IHN0YXR1cyA9IHBjbG9zZShmcCk7CisgICAgICAgICAgICAgICBpZiAoV0lGRVhJVEVEKHN0YXR1 cykgJiYgV0VYSVRTVEFUVVMoc3RhdHVzKSA9PSAwKQorICAgICAgICAgICAgICAgICBleGl0KDAp OworICAgICAgICAgICAgfQorICAgICAgICAgIGV4aXQoLTEpOworICAgICAgICB9CisjZW5kaWYK ICAgICAgICAgYWN0aW9uLnNhX2hhbmRsZXIgPSBTSUdfREZMOwogICAgICAgICBhY3Rpb24uc2Ff ZmxhZ3MgPSBTQV9PTlNUQUNLIHwgU0FfTk9ERUZFUiB8IFNBX1JFU0VUSEFORCB8IFNBX1NJR0lO Rk87CiAgICAgICAgIHNpZ2VtcHR5c2V0KCZhY3Rpb24uc2FfbWFzayk7Cg==