33043 2017-01-25 11:22:28 +0300 Разрешить имена, начинающиеся c цифры 2017-02-16 15:19:54 +0300 1 1 4 Development Sisyphus pam0_tcb unstable all Linux CLOSED WONTFIX RS P3 minor --- 1 ekorneechev ldv alex cas evg ldv mike nbr placeholder rider sin qa-sisyphus oldest_to_newest 161481 0 ekorneechev 2017-01-25 11:22:28 +0300 Проблема такая: BaseAlt Server 8.1, машина введена в домен https://www.altlinux.org/SSSD/AD В АД около 10000 пользователей, их логины имеют формат пятизначного числа, например 12345 (ну или 12345@company.local). Если пытаться авторизоваться через lightdm - ошибка "Не удается выполнить вход" через Ctrl+Alt+F2 - сразу после ввода логина ошибка "Login incorrect" $ su - 12345 su: Authentication token manipulation error Однако, если пытаться зайти по ssh на данный комп под такой УЗ - то все ОК: $ ssh 123456@localhost 123456@localhost's password: [123456@basealt8-fresh ~]$ Может есть какие варианты для снятия ограничений с имен пользователей? Про то, что это плохо - понимаем (совпадение UID и логина, проблемы в программах, которые основывают свою логику на анализе введенных данных, если введены цифры - значит это UID, GID и т.п.). Однако менять имена всех 10000 УЗ в АД - не вариант... 161482 1 ekorneechev 2017-01-25 11:24:43 +0300 Воркэраунд такой: $ su - company.local\\12345 $ getent passwd company.local\\12345 12345:*:10532:10000:12345:/home/COMPANY/12345:/bin/bash Для Ctrl+Alt+F*: Login: company.local\12345 161483 2 rider 2017-01-25 12:41:16 +0300 Женя, а в каких приложениях используется вход в AD, где нужна такая авторизация ? это только lightdm ? может быть в качестве варианта будет возможность настройки lightdm для авторизации исключельно в AD с жёсткой привязкой к домену ? 161485 3 ekorneechev 2017-01-25 13:38:30 +0300 (В ответ на комментарий №2) > Женя, а в каких приложениях используется вход в AD, где нужна такая авторизация > это только lightdm ? Например еще, авторизация в dovecot, с использованием доменных учетных записей (по емейл, привязанному в АД, вход выполняется) > может быть в качестве варианта будет возможность настройки lightdm для > авторизации исключельно в AD с жёсткой привязкой к домену ? А если домен будет недоступен и надо будет войти в иксы локальным админом? 161486 4 rider 2017-01-25 13:45:32 +0300 Хорошо, не с жёсткой привязкой ;) А авторизация в dovecot не по тикетам идёт ? 161492 5 ekorneechev 2017-01-25 15:51:53 +0300 (В ответ на комментарий №4) > Хорошо, не с жёсткой привязкой ;) > А авторизация в dovecot не по тикетам идёт ? Авторизация (БД паролей) настроена на PAM http://wiki2.dovecot.org/PasswordDatabase/PAM passdb { driver = pam } Оттуда видимо дальше sssd, а еще дальше тикеты? Таких подробностей я не знаю... 161495 6 ekorneechev 2017-01-25 17:44:44 +0300 (В ответ на комментарий №2 - из https://bugzilla.altlinux.org/show_bug.cgi?id=13649#c2) > Проверка, зашитая в pam_tcb (pam_sm_authenticate и pam_sm_chauthtok), явно > запрещает аутентификацию и смену пароля для аккаунтов, имена которых содержат > !isalpha символы. Может как-то можно это "по-быстрому" обойти =) ? (это же оно самое?) 161508 7 ekorneechev 2017-01-25 23:56:44 +0300 (В ответ на комментарий №6) > > Проверка, зашитая в pam_tcb (pam_sm_authenticate и pam_sm_chauthtok).... > Может как-то можно это "по-быстрому" обойти =) ? Решил сам собрать pam0_tcb без данной проверки - тестовое задание #177152. После обновления пакета из задания авторизация по цифровым логинам заработала, и в lightdm, и в login, и, что самое важное, в dovecot. Можно же оставить данное задание в "висячем" положении (уж больно удобно решить данный вопрос на большом количестве станций одной командой apt-repo test 177152 pam0_tcb)? 161509 8 rider 2017-01-26 08:01:15 +0300 Нет, не получится - придётся перезапускать время от времени это задание. 161510 9 ekorneechev 2017-01-26 09:00:24 +0300 (В ответ на комментарий №8) > Нет, не получится - придётся перезапускать время от времени это задание. Вообще, на первый взгляд достаточно подменить /lib64/security/pam_tcb.so на собранный в этом задании. Либо руками, либо может соберу новый пакет для этой цели. 161511 10 rider 2017-01-26 09:04:56 +0300 Поаккуратнее с этим, проверьте что бы этот пакет не влетал в систему по умолчанию при сборке дистрибутивов и не обновлял существующие системы. 161600 11 cas 2017-01-30 15:24:33 +0300 (В ответ на комментарий №7) > (В ответ на комментарий №6) > > > Проверка, зашитая в pam_tcb (pam_sm_authenticate и pam_sm_chauthtok).... > > Может как-то можно это "по-быстрому" обойти =) ? > > Решил сам собрать pam0_tcb без данной проверки - тестовое задание #177152. > После обновления пакета из задания авторизация по цифровым логинам заработала, > и в lightdm, и в login, и, что самое важное, в dovecot. > > Можно же оставить данное задание в "висячем" положении (уж больно удобно решить > данный вопрос на большом количестве станций одной командой apt-repo test 177152 > pam0_tcb)? Спасибо! Думаю, правильнее будет сделать опцию включаемой через конфигуратор и документировать эту опцию. 161605 12 ekorneechev 2017-01-30 17:11:02 +0300 Вот такой комментарий есть в исходниках: * Various libraries at various times have had bugs related to * '+' or '-' as the first character of a username. Don't take * any chances here. Require that the username starts with a * letter. Может стоит разрешить использовать в качестве первого символа в добавок цифру и '_', а не рубить на корню все !isalpha? 161912 13 ldv 2017-02-16 02:19:43 +0300 Разрешая числовые имена аккаунтов, вы открываете дорогу к undefined behavior в софте, который оперирует именами и идентификаторами аккаунтов. Например, если некий аккаунт имеет имя 1000, то априори неизвестен результат операции chown 1000 ФАЙЛ: то ли владельцем ФАЙЛа станет аккаунт по имени 1000, то ли аккаунт с идентификатором 1000. По этой причине я не рекомендую разрешать числовые имена аккаунтов. Я сожалею, что pam_tcb оказалось единственным местом в операционной системе, вставшем на вашем пути превращения ОС в тыкву. Я подумаю, что можно предпринять, чтобы в будущих версиях ОС это было не так просто сделать.