При настройке доверительных отношений между доменом FreeIPA и доменом Windows2008. Из FreeIPA домена нету доступа к пользователем из доверенного домена. Проблема в правах доступа на файл /etc/krb5.keytab Как временное решение можно назначить права 644: # chmod 644 /etc/krb5.keytab
Женя предлагает добавить ещё одну группу для доступа к keytab и всех клиентов вроде sssd включить в неё.
Вообще 600 root:root на keytab сам инсталлер freeipa ставит, AFAIR. Надо бы посмотреть как это работает в той же федоре, 600 мне нравится гораздо больше, чем 640.
в других дистрибутивах sssd работает от рута.
Казалось бы, keyctl в ядре с незапамятных времен, так нет же, будем /etc/krb5.keytab использовать, как будто прошлый век еще не закончился.
(In reply to comment #3) > в других дистрибутивах sssd работает от рута. Это меняет дело. Тогда мне больше нравится sssd не от рута и 640 на keytab. (In reply to comment #4) > Казалось бы, keyctl в ядре с незапамятных времен, так нет же, будем > /etc/krb5.keytab использовать, как будто прошлый век еще не закончился. Я не думаю, что мы прямо сейчас готовы переписывать sssd и freeipa.
Я запушил к себе в гит изменения для sssd, позволяющие дать krb5.keytab права на чтение для какой-нибудь группы. Осталось придумать ей название, добавить ее создание в krb5 и изменить права на этот файл. В sssd.spec нужно будет добавлять его пользователя в эту группу.
В качестве названия группы предлагается _keytab. Но мне бы не хотелось собирать sssd и krb5, там используется %ubt и если я буду готовить сборку, то у меня будет слишком большой соблазн убрать мусор из релиза. Ну и acl на эти пакеты у меня все равно нет.
Кому мусор, а кому снижение до нуля трудоёмкости бэкпорта в стабильный бранч. Женя, соберёшь sssd и krb5 с предлагаемыми изменениями ?
Да, я сделаю сборку. krb5 я уже начал смотреть на эту тему. Обнаружил, что есть два предусмотренных вида keytab-файлов, по умолчанию: $ git grep '\.keytab$' | grep configure.in configure.in: DEFKTNAME=FILE:/etc/krb5.keytab configure.in: DEFCKTNAME=FILE:$exp_localstatedir/krb5/user/%{euid}/client.keytab Для разработчиков они также доступны: $ grep keytab /usr/lib64/pkgconfig/krb5.pc defktname=FILE:/etc/krb5.keytab defcktname=FILE:/var/lib/kerberos/krb5/user/%{euid}/client.keytab
Надо сделать это по возможности срочно. (В ответ на комментарий №9) > Да, я сделаю сборку. krb5 я уже начал смотреть на эту тему. Обнаружил, что есть > два предусмотренных вида keytab-файлов, по умолчанию: > $ git grep '\.keytab$' | grep configure.in > configure.in: DEFKTNAME=FILE:/etc/krb5.keytab > configure.in: > DEFCKTNAME=FILE:$exp_localstatedir/krb5/user/%{euid}/client.keytab > > Для разработчиков они также доступны: > $ grep keytab /usr/lib64/pkgconfig/krb5.pc > defktname=FILE:/etc/krb5.keytab > defcktname=FILE:/var/lib/kerberos/krb5/user/%{euid}/client.keytab
Сборка отправлена в Сизиф: #178959 BUILDING #2 [locked] [test-only] sisyphus krb5.git=1.14.4-alt2%ubt sssd.git=1.14.2-alt5%ubt Сценариев для проверки достаточно много, прошу проверить на своих. Буду благодарен за просмотр (review) патча для krb5.
(In reply to comment #11) > Сборка отправлена в Сизиф: > #178959 BUILDING #2 [locked] [test-only] sisyphus krb5.git=1.14.4-alt2%ubt > sssd.git=1.14.2-alt5%ubt Просьба расшарить таск, я добавлю туда freeipa с соответствующими изменениями. > Сценариев для проверки достаточно много, прошу проверить на своих. Буду > благодарен за просмотр (review) патча для krb5. Я взглянул, что сразу заметно: - Если нужно проверять errno после getgrnam_r, то перед вызовом нужно делать errno = 0. Иначе там может оказаться что угодно. - Нет проверки fchown&fchmod на успешность. Хотя может это и не важно, делать что-то в случае ошибки вряд ли нужно, если только сообщение вывести.
"Таску расшарил": #178959 NEW #2 [shared] [test-only] sisyphus krb5.git=1.14.4-alt2%ubt sssd.git=1.14.2-alt5%ubt > Я взглянул, что сразу заметно: > - Если нужно проверять errno после getgrnam_r, то перед вызовом нужно делать > errno = 0. Иначе там может оказаться что угодно. Поправил, спасибо. > - Нет проверки fchown&fchmod на успешность. Хотя может это и не важно, делать > что-то в случае ошибки вряд ли нужно, если только сообщение вывести. Да, тут пока не вижу смысла... Нужно разобраться в выводе логов, а иначе смысл проверки теряется.
# ls -al /etc/krb5.keytab -rw-r----- 1 root _keytab 184 фев 5 2018 /etc/krb5.keytab # id _sssd uid=484(_sssd) gid=462(_sssd) группы=462(_sssd),491(_keytab) libkrb5-1.16.2-alt2 sssd-2.0.0-alt3.gitf0603645f
