Bug 33115 - FreeIPA не доступны пользователи из доверенного домена
Summary: FreeIPA не доступны пользователи из доверенного домена
Status: CLOSED WORKSFORME
Alias: None
Product: Sisyphus
Classification: Development
Component: sssd (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Evgeny Sinelnikov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-15 14:47 MSK by Sergey Novikov
Modified: 2018-12-20 09:57 MSK (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Novikov 2017-02-15 14:47:00 MSK
При настройке доверительных отношений между доменом FreeIPA и доменом Windows2008. Из FreeIPA домена нету доступа к пользователем из доверенного домена.
Проблема в правах доступа на файл /etc/krb5.keytab
Как временное решение можно назначить права 644:
# chmod 644 /etc/krb5.keytab
Comment 1 Anton Farygin 2017-02-19 09:23:03 MSK
Женя предлагает добавить ещё одну группу для доступа к keytab и всех клиентов вроде sssd включить в неё.
Comment 2 Mikhail Efremov 2017-02-19 13:13:10 MSK
Вообще 600 root:root на keytab сам инсталлер freeipa ставит, AFAIR.
Надо бы посмотреть как это работает в той же федоре, 600 мне нравится гораздо больше, чем 640.
Comment 3 Anton Farygin 2017-02-19 14:28:31 MSK
в других дистрибутивах sssd работает от рута.
Comment 4 Dmitry V. Levin 2017-02-20 01:57:34 MSK
Казалось бы, keyctl в ядре с незапамятных времен, так нет же, будем /etc/krb5.keytab использовать, как будто прошлый век еще не закончился.
Comment 5 Mikhail Efremov 2017-02-20 15:11:35 MSK
(In reply to comment #3)
> в других дистрибутивах sssd работает от рута.

Это меняет дело. Тогда мне больше нравится sssd не от рута и 640 на keytab.

(In reply to comment #4)
> Казалось бы, keyctl в ядре с незапамятных времен, так нет же, будем
> /etc/krb5.keytab использовать, как будто прошлый век еще не закончился.

Я не думаю, что мы прямо сейчас готовы переписывать sssd и freeipa.
Comment 6 Mikhail Efremov 2017-02-22 15:38:27 MSK
Я запушил к себе в гит изменения для sssd, позволяющие дать krb5.keytab права на чтение для какой-нибудь группы. Осталось придумать ей название, добавить ее создание в krb5 и изменить права на этот файл.
В sssd.spec нужно будет добавлять его пользователя в эту группу.
Comment 7 Mikhail Efremov 2017-02-22 15:51:39 MSK
В качестве названия группы предлагается _keytab.
Но мне бы не хотелось собирать sssd и krb5, там используется %ubt и если я буду готовить сборку, то у меня будет слишком большой соблазн убрать мусор из релиза.
Ну и acl на эти пакеты у меня все равно нет.
Comment 8 Anton Farygin 2017-02-22 16:04:51 MSK
Кому мусор, а кому снижение до нуля трудоёмкости бэкпорта в стабильный бранч. 
Женя, соберёшь sssd и krb5 с предлагаемыми изменениями ?
Comment 9 Evgeny Sinelnikov 2017-02-24 14:28:12 MSK
Да, я сделаю сборку. 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
Comment 10 Anton V. Boyarshinov 2017-02-27 18:02:45 MSK
Надо сделать это по возможности срочно.

(В ответ на комментарий №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
Comment 11 Evgeny Sinelnikov 2017-02-28 06:09:57 MSK
Сборка отправлена в Сизиф:
#178959 BUILDING #2 [locked] [test-only] sisyphus krb5.git=1.14.4-alt2%ubt sssd.git=1.14.2-alt5%ubt

Сценариев для проверки достаточно много, прошу проверить на своих. Буду благодарен за просмотр (review) патча для krb5.
Comment 12 Mikhail Efremov 2017-02-28 16:08:51 MSK
(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 на успешность. Хотя может это и не важно, делать что-то в случае ошибки вряд ли нужно, если только сообщение вывести.
Comment 13 Evgeny Sinelnikov 2017-02-28 16:51:44 MSK
"Таску расшарил":
#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 на успешность. Хотя может это и не важно, делать
> что-то в случае ошибки вряд ли нужно, если только сообщение вывести.

Да, тут пока не вижу смысла... Нужно разобраться в выводе логов, а иначе смысл проверки теряется.
Comment 14 Anton Farygin 2018-12-20 09:57:36 MSK
# 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