[samba] Fwd: libwbclient от samba и sssd
Evgeny Sinelnikov
sin на altlinux.ru
Вт Ноя 29 23:07:04 MSK 2016
29 ноября 2016 г., 17:03 пользователь Alexander Bokovoy <ab на samba.org> написал:
> On ti, 29 marras 2016, Evgeny Sinelnikov wrote:
>> 29 ноября 2016 г., 14:34 пользователь Michael Shigorin
>> <mike на altlinux.org> написал:
>> > On Tue, Nov 29, 2016 at 02:05:45PM +0300, Evgeny Sinelnikov wrote:
>> >> Таким образом имеет смысл разобраться с зависимостями и решить
>> >> - стоит ли вообще использовать альтернативы, если у нас имеются
>> >> пакеты, которые зависят от функционала, реализованного только в
>> >> заданной версии libwbclient?
>> >
>> > Для библиотек с различным ABI это заведомая диверсия.
>>
>> Вопрос о намерениях - это отдельный вопрос. Обычно всё объясняется
>> недопониманием технических деталей. Тем более, так сделано в Fedora. А
>> у нас, как у них.
>>
>> Тем не менее... у нас пакет gssntlmssp, вытягивает за собой
>> libwbclient-sssd даже на сервере, где уже, вроде как, установлен
>> /usr/lib64/samba-dc/libwbclient.so.0.13 (в пакете samba-DC-libs), но
>> для него альтернативы не используются. Предполагается, что в samba и
>> samba-DC эта библиотека собирается практически одинаково.
>>
>> При этом "... libwbclient-sssd не реализует аутентификацию по NTLMSSP".
>> И тогда возникает вопрос: "Есть смысл в альтернативах при таком раскладе?"
>>
>> Если есть, то нужно уточнить для чего и поправить зависимости для
>> пакета gssntlmssp, от которого зависят плагины pidgin-sipe и
>> telepathy-sipe.
>> $ apt-cache whatdepends gssntlmssp
>> gssntlmssp-0.6.0-alt1.qa1
>> gssntlmssp-devel-0.6.0-alt1.qa1
>> Требует: gssntlmssp = 0.6.0-alt1.qa1
>> i586-gssntlmssp.32bit-0.6.0-alt1.qa1
>> Требует: gssntlmssp = 0.6.0-alt1.qa1
>> telepathy-sipe-1.20.1-alt1
>> Требует: gssntlmssp
>> pidgin-sipe-1.20.1-alt1
>> Требует: gssntlmssp
>>
>> Хотя, в принципе, получается, что для сервера можно тогда ничего не
>> менять, потому что gssntlmssp нужен только на клиентах, где вполне
>> может использоваться sssd и libwbclient-sssd. И при этом остаётся
>> другой вопрос: "Совместим ли gssntlmssp с libwbclient-sssd?"
> Нет, gssntlmssp не может работать через libwbclient-sssd.
>
> gssntlmssp нужен там, где не используется инфраструктура Kerberos,
> потому что в противном случае выбора модуля gss-ntlmssp не произойдет.
> Это означает, что либо клиент, либо сервер не включены в домен AD или
> FreeIPA. В этом случае использовать libwbclient-sssd смысла никакого
> нет.
>
> Основная проблема в том, что пакетные зависимости не дают возможность
> корректно выразить все эти конфигурации.
Да, спасибо, Александр. Я уже открыл два git репозитория:
- у нас:
http://git.altlinux.org/gears/s/sssd.git
http://git.altlinux.org/gears/g/gssntlmssp.git
- и в апстриме:
https://git.fedorahosted.org/git/sssd.git
https://git.fedorahosted.org/git/gss-ntlmssp.git
Посмотрел код и всё понял. Возможно, это просто. Но мне это не кажется
очевидным. Поэтому я переформулирую, а вы поправьте, если я ошибся.
Вариант использования (aka "use case") для libwbclient-sssd следующий:
- мы хотим уйти от старого хлама (вроде NTLM) и оставить чистый Kerberos;
- мы установили на клиенте аутентификацию и авторизацию через sssd;
- но, кроме PAM и NSS, у нас есть на клиенте Samba:
+ как клиент, если мы обращаемся за шарами, например;
+ как сервер, если сами что-то шарим;
- и вот сборках, этой самой Samba, этот хлам (от которого мы хотели
избавиться) имеется в клиентской стороне в недрах библиотеки
libwbclient;
- и мы, волевым решением, пытаемся от неё избавиться...
И тут выясняется, что:
$ ldd /usr/lib64/libsmbclient.so.0 | grep libwbclient
libwbclient.so.0 => /usr/lib64/libwbclient.so.0 (0x00007f77c4963000)
$ rpm -qf /usr/lib64/libsmbclient.so.0
libsmbclient-4.5.1-alt1
$ apt-cache whatdepends libsmbclient | grep -v libsmbclient
samba-libs-4.5.1-alt1
opennx-0.16.e-alt30
wcmcommander-0.20.0-alt1
vlc-plugin-smb-2.2.4-alt1
sssd-ad-1.14.1-alt1.M80P.1
smbnetfs-0.5.3a-alt2.1
python3-module-smbc-1.0.15.3-alt1.1
python-module-smbc-1.0.15.3-alt1.1
mpv-0.16.0-alt2
libmpv1-0.16.0-alt2
mplayer-1.1.1-alt16
mencoder-1.1.1-alt16
xine2-plugin-samba-1.2.6-alt2
xine-plugin-samba-1.1.21-alt7
kodi-16.1-alt0.M80P.1
kdebase-kio-3.5.13.2-alt7.3
kde5-kio-extras-16.08.3-alt0.M80P.1
kde4base-runtime-core-16.04.1-alt2
gvfs-backend-smb-1.28.3-alt1
libgnustep-SMBKit-20140126-alt2.cvs20140126
gnome-vfs-module-smb-1:2.24.4-alt10
gnome-control-center-3.20.2-alt0.M80P.1
fuse-smb-0.8.7-alt4
libcsync-0.50.6-alt1
И всё это хозяйство куда обращается за списками пользователей и
группами? Правильно, не явно, к winbind'у. А при использовании sssd у
нас его может и не быть. Хотя можно себе представить, что запущены
оба.
И какое же решение мы принимаем?
Правильно, мы делаем параллельную реализацию без всякого "хлама"
(только NSS от sssd плюс трансляция SID'ов в UID'ы и никакого PAM от
winbind):
/* Authenticate a user with cached credentials */
wbcErr wbcCredentialCache(struct wbcCredentialCacheParams *params,
struct wbcCredentialCacheInfo **info,
struct wbcAuthErrorInfo **error)
{
if (error != NULL) {
*error = NULL;
}
WBC_SSSD_NOT_IMPLEMENTED;
}
И, по умолчанию, если libwbclient-sssd установлена, у нас работает именно она.
Таким образом, мы получаем не диверсию, а планомерное выпиливание
нежелательного функционала. Потенциально уязвимого и небезопасного
наследия, которое тянется со времён NT4. То есть для совместимости с
доменами до Windows 2000 и... внимание, с доменами на базе Samba3.
В принципе, всё что использует gssntlmssp не имеет смысла использовать
совместно с sssd и тем более странно, что при его установке
вытягивается именно libwbclient-sssd, а не обычный libwbclient. Вот
это надо исправить, я думаю, явной зависимостью.
Всё это понятно, если почитать код, но мне не кажется очевидным.
____________________________
Далее... Какое же решение мы принимаем по поводу альтернативы для
libwbclient и libwbclient-sssd?
- Мейнтенить sssd и samba - получается, нужно совместно.
- А на клиентской стороне стараться использовать только libwbclient-sssd и sssd.
И... тогда получается, что у нас всё даже почти правильно.
Но apt не должен никогда вытягивать libwbclient-sssd, по умолчанию,
для любых клиентов, кроме sssd. И только, когда sssd установлен,
должен вытягиваться libwbclient-sssd и заменять собой libwbclient.
И ещё... в связи с этим возникают следующие вопросы:
- Так ли на надёжен libwbclient-sssd? Где и когда нам может
потребоваться winbind? Есть такие конфигурации?
- Как быть с использованием libwbclient-sssd (и sssd, вообще) на
серверном узле, где установлен контроллер домена из пакета samba-DC?
Ведь тогда, вообще, все клиенты нужно линковать с
/usr/lib64/libwbclient.so.0, кроме внутренних.
- И где граница? smbclient - это же тогда внешний клиент, или как?
____________________________
В итоге, возникают более сложные вопросы:
- Какие, конкретно, конфигурации "пакетные зависимости не дают
возможность корректно выразить"? Мне непонятно.
- Что мы хотим получить альтернативами, если библиотека, в заданный
момент, всё равно выбрана одна и вполне конкретная? Какие возможности?
Я вижу только одну понятную возможность. Чтобы выпилить весь старый
хлам, нужно быстро уметь проверить - работает всё без него или нет. И
только в этом я пока вижу смысл именно альтернатив.
--
Sin (Sinelnikov Evgeny)
Подробная информация о списке рассылки Samba