Вход:  Пароль:  
FreeSource: NotUnixWay ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Проблемы Unix Way 


Основной целью этой статьи является прояснение технических проблем использования классического Unix Way на практике. Первый вариант этой статьи был написан как комментарий к статье идеология Linux в отношении к части о проявлении вреда (Free|Open)Source. К сожалению, комментарий канул в лету, но его копия чудом сохранилась.


Оглавление документа

Проблемы


У современных систем средства класса IPC (в классическом случае это каналы и параметры, переданные приложению как подстановка строки выданной другим приложением) имеют тенденцию объединяться с RPC. Конечно, сетевое взаимодействие можно также представить в виде взаимодействия приложений передающих команды через параметры командной строки и каналы. Но так нигде не сделано. Во-первых это связано с проблемами безопасности и сетевой аутентификацией, во-вторых – с необходимостью адекватной авторизации, где немаловажную роль играют идентификаторы (aka uid и gid).

Пример

Например, рассмотрим следующий пример – нужно перезапустить сервис на удалённом хосте.

  1. Решение стандартное:

  1. Решение MIT'based with KDC:

Причины


Из основных свойств архитектуры Unix, следует, классический unix-way не предполагает, что программа может быть запущена вне рамок локального процесса. А это означает, невозможность запуска команды или серии команд и их удалённого выполнения. А если таких задач становится много? Некоторые решаются и создают свои велосипеды или протоколы, но обычно над этим никто не задумывается до самого последнего момента. Природа запуска приложений в Unix такова, что аутентификация тесно связана идентификатором пользователя от имени которого выполняются все приложения в рамках сессии. Для типичных команд в Unix роль среды для сессии выполняет называемая оболочка или командный интерпретатор. Эта сессия запускается тв или иначе в виде процесса, кторому присваивается соответствующий идентификатор. Именно этот идентификатор определяет права пользователя в локальной системе, для удалённого же хоста требуется сетевая аутентификация. Вообще тема сетевой аутентификации – это сложная и запутанная вещь. Чтобы в неё вникнуть нужно осознать как работает локальная. А локальная же работает достаточно просто. При входе в систему, на основании удачного завершения действия auth, правильно сконфигурированных модулей PAM, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и группы (gid). Далее это сохраняется на время всей сессии и аутентификация проводится ядром прозрачно на уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в общем виде назовём их по эффективными. Права на смену этих идентификаторов есть только у супер-пользователя. В этом плане существует ещё большая проблема. Авторизоваться в Unix Way стандартными методами ядра возможна только посредством файловой системы. Всё остальное – это надстройки и костыли...

Пример


Например возьмём ещё одну простую задачу – обратиться от имени пользователя к локальному сервису. Что для этого существует?

  1. Сокет по некому порту
  2. Именованный канал
  3. Файл сокета

Последние два находятся на файловой системе и для работы с ними требуется каким-либо образом передать клиенту имя файла для обращения к сервису. Для этого обычно используются, например в D-BUS, переменные окружения или файлы настройки в домашнем каталоге. В первом случае, чтобы клиент мог воспользоваться таким сервисом, этот сервис должен быть запущен до запуска его клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана соответствующая переменная окружения. Во втором же случае, должен существовать либо путь, вычисляемый по умолчанию, либо отдельная настройка под каждого клиента. В любом случае, при использовании файлов, авторизовывать клиента целесообразно только на уровне доступа к этому файлу (с помощью группы или ACL), что означает необходимость создания разных файлов для разных клиентов, чтобы отличать их друг от друга. В самом удачном варианте это требует создания сложной инфраструктуры для поддержки этого механизма. Если таких служб станет много, то без шаблонов привилегий тут не обойтись... Одним из вариантов стандартизации на этом уровне является связка HAL/D-BUS/PolicyKit


Тем не менее, в своём большинстве, в силу необходимости удалённого управления, большинство решений, например mpd, работают с помощью сокетов. И тут возникает весьма не простая вещь. Возникает новый класс сетевых пользователей, даже если эти пользователи на самом деле локальные. Любая задача вида:

требует отдельной аутентификации... В самом небезопасном случае, это означает, что по домашнему каталогу пользователя и по /etc начинают расползаться вбитые пароли. А что если пароль измениться? Его придётся изменять у всех клиентов. Кроме того это не удобно для сервера – у него нет стандартного средства кроме PAM, и он вынужден каждый раз требовать пароль.

Следствия


Многие задачи, как в показанном в начале примере, решаются поверх протокола SSH, но полноценный RPC на нём сделать не просто, поскольку он не предназначен для решения всего спектра задач необходимых при удалённом управлении. Прежде всего потому, что спроектирован как удалённая консоль и для использования системными службами не предназначен.


Связи между реализациями классического Unix Way и современными задачами, требующими сетевой аутентификации и авторизации нет. Именно это мешает сделать простым запуск команды на удалённом хосте. Отсутствие этой связи можно проследить отсутствием связи между отдельными подсистемами ядра, поскольку именно на уровне ядра происходит распределение полномочий процессов. Сетевая аутентификация и авторизация никак на вписывается в Unix Way, поскольку реализуется на прикладном уровне. Здесь ещё не хватает сетевой файловой системы и соответствия между uid'ами и gid'ами на локальном и удалённом хостах. Это тоже не вписывается в текущие реализации классического Unix Way.

Результат


Основную мысль рассуждения, хотелось бы завершить следующим резюме. Пока не будет придумана и реализована общая схема интеграции IPC и RPC, пока не будут организованы стандартные средства и API для единой и прозрачной сетевой и локальной аутентификации, пути к современным корпоративным средам у Unix Way нет. К сожалению, к моменту когда они будут реализованы, всё уже тоже может оказаться слишком далеко ушедшим. Это уже сейчас почти так...

Варианты решений


На самом деле всё уже есть. Есть Kerberos и именно он используется в w2k3, и именно про него апеллируют к MIT. Хотя в w2k3 он не совсем такой, какой он у MIT. Он использует некоторые поля, которые в стандарте можно использовать для своих целей разработчикам, для передачи авторизационной информации. Что же даёт Kerberos? Он даёт необходимую прозрачную сетевую аутентификацию. Почему же он не используется повсеместно? Потому, что усложняет программы (есть даже такой термин керберизация). Керберизация означает однозначное завязывание на одну библиотеку и один вариант аутентификации, а использование стандартного PAM требует ввода пароля “by design”. Есть попытка сделать более стандартную обёртку – GSSAPI. К сожалению, эта обёртка на практике очень капризна (требует DNS, что одноранговых сетях можно заменить на Avahi) – многие разработчики и администраторы её не очень жалуют, хотя за всех сказать конечно не возьмусь... Кроме того Kerberos требует выделенного сервера – KDC, то есть керберизация в одноранговой сети не предусмотрена. Интерфейсы же приложений, тем более если они сетевые, могут быть любыми удобными, поскольку никакой unix-way не решает вопроса глобальной сетевой аутентификации. Открываем сокет.... И там уже что ни попадя... SSL, HTTPS, OpenID, Kerberos, ...

Ссылки


Страницы, ссылающиеся на данную: TZ/СерверИнтеграции


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]