Основной целью этой статьи является прояснение технических проблем использования классического Unix Way на практике.
Первый вариант этой статьи был написан как комментарий к статье идеология Linux в отношении к части о проявлении вреда (Free|Open)Source.
К сожалению, комментарий канул в лету, но его копия чудом сохранилась.
У современных систем средства класса IPC (в классическом случае это каналы и параметры, переданные приложению как подстановка строки выданной другим приложением)
имеют тенденцию объединяться с RPC. Конечно, сетевое взаимодействие можно также представить в виде взаимодействия приложений передающих команды через параметры
коммандной строки и каналы. Но так нигде не сделано. Во-первых это связано с проблемами безопасности и сетевой аутентификацией, во-вторых – с необходимостью адекватной
авторизации, где немаловажную роль играют идентификторы (aka uid и gid).
Например, рассмотрим следующий пример – нужно перезапустить сервис на удалённом хосте.
Из основных свойств архитектуры Unix, следует, классический unix-way не предполагает, что программа не может быть запущена вне рамок локального процесса.
А это означает, невозможность запуска команды или серии комманд и удалённого выполнения. А если таких задач становится много? Некоторые решаются и создают
свои велосипеды или протоколы, но обычно над этим никто не задумывается до самого последнего момента. Природа запуска приложений в Unix такова, что аутентификация
тесно связана идентификатором пользователя от имени которого выполняются все приложения в рамках сессии. Для типичных команд в Unix это так называемая или
коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в локальной системе, для удалённого же хоста требуется сетевая аутетнификация.
Вообще тема сетевой аутентификации – это сложная и запутанная вещь. Чтобы в неё вникнуть нужно осознать как работает локальная. А локальная же работает достаточно
просто. При входе в систему, на основании удачного завершения действия auth, правильно скофигурированных модулей PAM, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и группы (gid). Далее это сохраняетя на время всей сессии и аутентификация проводится ядром прозрачно на уровне локального хоста.
Важным моментов является выделение нескольких видов идентификаторов, в общем виде назовём их по эффективными. Права на смену этих идентификаторов есть только у
супер-пользоателя. В этом плане существует ещё большая проблема. Авторизоваться в Unix Way стандартными методами ядра возможна только посредством файловой системы.
Всё остальное – это надстройки и костыли...
Например воьзмём ещё одну простую задачу – обратиться от имени пользователя к локальному сервису. Что для этого существует?
Последние два находятся на файловой системе и для работы с ними требуется каким-либо образом передать клиенту имя файла для обращения к сервису. Для этого
обычно используются, например в D-BUS, переменные окружения. То есть, что бы клиент мог им воспользоваться сервис должен быть запущен до клиента и родительскому
процессу всего дерева процессов пользователя должна быть передана соотвествующая переменная окружения. С другой стороны это может быть файл в домашнем
каталоге пользователя. Но тогда возникает вопрос о том, как быть, если сервис запущен не от имени пользователя. Вероятно с помощью ACL или группы.
И то и другое требует действий администратора как во время настройки, так и во время добавления новых пользователей. Если таких служб станет много, то без
шаблонов привилегий тут не обойтись...
Тем не менее, в своём большинстве, в силу необходимости удалённого управления, большинство решений, например mpd, работают с помощью сокетов. И тут возникает
весьма не простая вещь. Возникает новый класс сетевых пользователей, даже если эти пользователи на самом деле локальные. Любая задача вида:
требует отдельной аутентификации... В самом небезопасном случае, это означает, что по домашнему каталогу пользователя и по /etc/ начинают расползаться вбитые пароли.
А что если пароль измениться? Его придётся изменять у всех клиентов. Кроме того это не удобно для сервера – у него нет стандартного средства кроме PAM, и он вынужден
каждый раз требовать пароль.
Что же здесь ещё не учтено... Ага здесь ещё не хватает сетевой файловой системы. И соответствия между uid'ами и gid'ами на локальном и удалённом хостах.
Вроде всё из основных проблем... Если вы ещё не потеряли мысль рассуждения, то завершить его хотелось бы следующим. Пока не будет придумана и реализована
общая схема интеграции IPC и RPC, пока не будут орагнизованы стандарные средства и API для единой и прозрачной сетевой и локальной аутентификации, пути
к современным корпоративным средам у Unix Way нет. К сожалению, к моменту когда они будут реализованы, всё уже тоже может оказаться слишком далеко ушедшим.
Это уже сейчас почти так...
На самом деле всё уже есть. Есть Kerberos и именно он используется в w2k3, и именно про него аппелируют к MIT. Хотя в w2k3 он не совсем такой, какой он у MIT.
Он использует некоторые поля, которые в стандарте можно использовать для своих целей разработчикам, для передачи авторизационной информации. Что же даёт Kerberos?
Он даёт необходимую прозрачную сетевую аутентификацию. Почему же он не используется повсеместно? Потому, что усложняет программы (есть даже такой
термин керберизация). Керберизация означает однозначное завязывание на одну библиотеку и один вариант аутентификации, а использование стандартного PAM
требует ввода пароля. Есть попытка сделать более стандартную обёртку – GSSAPI. К сожалению, эта обёртка на практике очень капризна (требует DNS, что
одноранговых сетях заменяется сейчас Avahi) – многие разработчики и администраторы её не очень жалуют, хотя за всех сказать конечно не возьмусь... Кроме
того Kerberos требует выделенного сервера – KDC, то есть кербризация в одноранговой сети не предусмотрена. Интерфейсы же приложений, тем более
если они сетевые, могут быть любыми удобными, поскольку никакой unix-way не решает вопроса глобальной сетевой аутентификации. Открываем сокет....
И там уже что ни поподя... SSL, HTTPS, OpenID, Kerberos, ...
Powered by WackoWiki R4.2
Wikipedia about Unix Way