From: "Dmitry V. Levin" <ldv@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] Смена глобального пароля Date: Sat, 4 Mar 2017 03:50:22 +0300 Message-ID: <20170304005022.GC24806@altlinux.org> (raw) In-Reply-To: <CAK42-Gq3esY0w8WWk2PDjn1KegrG11DuO6zuQRXjn420voDctQ@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 5465 bytes --] On Fri, Mar 03, 2017 at 01:27:08PM +0400, Evgeny Sinelnikov wrote: > Здравствуйте, > > Хочу обсудить проблему смены глобального пароля (то есть сетевого > пароля через LDAP, Kerberos и др. возможные механизмы) по мотивам > #33163 - Смена Kerberos-пароля для pam_krb5: > https://bugzilla.altlinux.org/show_bug.cgi?id=33163 > > В сущности, проблемы выглядит следующим образом - привожу цитату из > багзилы по поводу настроек PAM, по умолчанию, для смены пароля через > pam_krb5: > > > > Вообще, зачем применять такую связку? > > > password required pam_passwdqc.so config=/etc/passwdqc.conf > > > password [success=2 default=ignore] pam_tcb.so use_authtok shadow > > > fork prefix=$2y$ count=8 nullok write_to=tcb > > > password requisite pam_succeed_if.so uid >= 500 quiet > > > password required pam_krb5.so use_authtok > > > > > > Весь её смысл в том, что если Kerberos-пароль изменён успешно, то заменить, > > > заодно, и локальный пароль... Но нужно ли так делать??? > > > > Тут написано другое: сперва поменять локальный пароль с помощью pam_tcb, а если > > это не получилось и uid >= 500, то поменять нелокальный пароль с помощью > > pam_krb5. Странно если это не работает. На самом деле это некоторое упрощение, ведь password stack работает в два прохода, PAM_PRELIM_CHECK (который опрашивает модули) и PAM_UPDATE_AUTHTOK (который меняет пароли). Кроме того, приложение определяет, менять пароль всегда (как это делает passwd) или только по истечении срока действия (PAM_CHANGE_EXPIRED_AUTHTOK, как это делает login). Когда в password stack попадают два модуля, каждый из которых при некоторых условиях может поменять соответствующий пароль (как pam_tcb с pam_krb5 в этом примере), становится весело. На предварительной стадии первый же модуль в passwd stack, который успешно проверил введённый пользователем прежний пароль, сохраняет его в PAM_OLDAUTHTOK, и все остальные модули, как правило, будут проверять только этот пароль. На стадии смены пароля новый пароль, введённый пользователем по запросу одного модуля, используется последующими модулями, у которых указан параметр use_authtok. При этом если на предварительной стадии какой-то модуль в passwd stack вернул ошибку, то это не значит, что на стадии смены пароля этому модулю не будет дана возможность поменять пароль. Когда в password stack попадают более двух модулей, меняющих пароль, предсказать их поведение становится ещё немного сложнее. > Хочу обратить внимание на то, что текущий сценарий смены глобальных > паролей опирается на весьма сомнительную особенность, характерную для > unix-систем и совершенно не очевидную для пользователей корпоративных > решений. > > Дело в том, что механизмы аутентификации и авторизации, вообще говоря, > совершенно независимы и явно доступны для настройки. Таким образом, у > глобального пользователя может быть, как локальный, так и глобальный > пароли. > > И у нас, как и везде, применяется, по умолчанию, гибридная схема смены пароля: > - если локальный пароль подошёл, то меняем его, а если нет... то > меняем глобальный. > > Кроме того, что эта схема сейчас, вообще, не работает, возникает более > существенный вопрос (допустим она может заработать): "А зачем мы её > применяем по, умолчанию?" Видимо потому, что универсальной устраивающей всех схемы не существует, а по умолчанию надо предложить какую-нибудь универсальную конфигурацию. PAM это очень гибкий инструмент, который подходит для настройки под конкретную задачу. > Что же, собственно, происходит? > 1. Вместо смены глобального пароля, меняется локальный. В этом > основная проблема. > 2. Вопреки ожиданиям, текущий пароль может запрашиваться дважды. > Собственно, только неправильно задав один вид пароля, можно перейти к > попытке проверить другой вид пароля. > 3. Вывод строк запроса на ввод текущего (а иногда и нового) пароля, > для каждого PAM модуля может быть разным. В связи с чем мы имеем не > рабочий userpasswd: > https://bugzilla.altlinux.org/show_bug.cgi?id=33097 > > При этом, если поменять порядок модулей, и первым поставить проверку > глобального пароля, вместо локального, то всё вроде начинает > отрабатывать. > __________________________________________ > > В связи с перечисленным предлагаю обсудить "правильный" набор настроек > PAM и, вообще, подход к смене глобальных паролей. > > Может быть, не стоит пытаться "угадывать" какой пароль мы меняем, а > ввести для каждого типа отдельный вариант настройки вроде > passwd.local, passwd.sssd? > https://bugzilla.altlinux.org/show_bug.cgi?id=33163#c4 > > Ну, или, по крайней мере, если используется настройка с глобальными > паролями, в первую очередь пытаться изменить глобальный? Или, вообще, > только глобальный, а локальный изменять отдельной утилитой > passwd.local? Мы можем сделать passwd.local, это нам практически ничего не стоит, да и и passwd.какой_нибудь_другой_вариант тоже можем упаковать. Когда в passwd stack только один модуль, меняющий пароль, всё становится гораздо проще. Надо только знать, какой именно вариант passwd вызывать. А откуда это можно знать? Вероятно, лучше было бы обучить каждый модуль, который меняет пароль, при указании специального параметра определять, является ли данный PAM_USER локальным для этого модуля. Тогда можно было бы попробовать сохранить универсальное решение. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]
prev parent reply other threads:[~2017-03-04 0:50 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-03 9:27 Evgeny Sinelnikov 2017-03-04 0:50 ` Dmitry V. Levin [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170304005022.GC24806@altlinux.org \ --to=ldv@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git