http://freesource.info/wiki/NotUnixWay History/revisions of FreeSource/NotUnixWay en-us http://freesource.info/wiki/NotUnixWay/show?time=2008-02-15+04%3A59%3A58 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".notunixway" href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-15+04%3A59%3A58">2008-02-15 04:59:58</a> и <a href="http://freesource.info/wiki/NotUnixWay">2008-02-26 14:59:38</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">У&nbsp;современных систем средства класса IPC&nbsp;(в классическом случае это&nbsp;каналы и&nbsp;параметры, переданные приложению как&nbsp;подстановка строки выданной другим приложением) имеют тенденцию объединяться с&nbsp;RPC. Конечно, сетевое взаимодействие можно также представить в&nbsp;виде взаимодействия приложений передающих команды через параметры командной строки и&nbsp;каналы. Но&nbsp;так нигде не&nbsp;сделано. Во-первых это&nbsp;связано с&nbsp;проблемами безопасности и&nbsp;сетевой аутентификацией, во-вторых &ndash; с&nbsp;необходимостью адекватной авторизации, где&nbsp;немаловажную роль играют идентификаторы (aka uid&nbsp;и&nbsp;gid). <br /> Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии команд и&nbsp;их удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix роль среды для&nbsp;сессии выполняет называемая оболочка или&nbsp;командный интерпретатор. Эта&nbsp;сессия запускается тв&nbsp;или иначе в&nbsp;виде процесса, кторому присваивается соответствующий идентификатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутентификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно сконфигурированных модулей <a name="texnologii.pam" href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняется на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользователя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли... <br /> Например возьмём ещё одну простую задачу &ndash; обратиться от&nbsp;имени пользователя к&nbsp;локальному сервису. Что&nbsp;для этого существует?<br /> Последние два&nbsp;находятся на&nbsp;файловой системе и&nbsp;для работы с&nbsp;ними требуется каким-либо образом передать клиенту имя&nbsp;файла для&nbsp;обращения к&nbsp;сервису. Для&nbsp;этого обычно используются, например в&nbsp;D-BUS, переменные окружения или&nbsp;файлы настройки в&nbsp;домашнем каталоге. В&nbsp;первом случае, чтобы клиент мог&nbsp;воспользоваться таким сервисом, этот сервис должен быть запущен до&nbsp;запуска его&nbsp;клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана соответствующая переменная окружения. Во&nbsp;втором же&nbsp;случае, должен существовать либо путь, вычисляемый по&nbsp;умолчанию, либо отдельная настройка под&nbsp;каждого клиента. В&nbsp;любом случае, при&nbsp;использовании файлов, авторизовывать клиента целесообразно только на&nbsp;уровне доступа к&nbsp;этому файлу (с помощью группы или&nbsp;ACL), что&nbsp;означает необходимость создания разных файлов для&nbsp;разных клиентов, чтобы отличать их&nbsp;друг от&nbsp;друга. В&nbsp;самом удачном варианте это&nbsp;требует создания сложной инфраструктуры для&nbsp;поддержки этого механизма. Если таких служб станет много, то&nbsp;без шаблонов привилегий тут&nbsp;не&nbsp;обойтись... Одним из&nbsp;вариантов стандартизации на&nbsp;этом уровне является связка HAL/D-BUS/PolicyKit<br /> Основную мысль рассуждения, хотелось бы&nbsp;завершить следующим резюме. Пока не&nbsp;будет придумана и&nbsp;реализована общая схема интеграции IPC&nbsp;и&nbsp;RPC, пока не&nbsp;будут организованы стандартные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути к&nbsp;современным корпоративным средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим. Это&nbsp;уже сейчас почти так...<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него апеллируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у MIT. Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же&nbsp;даёт Kerberos? Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть даже такой термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартного PAM&nbsp;требует ввода пароля &#8220;by design&#8221;. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что&nbsp;одноранговых сетях можно заменить на&nbsp;Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть керберизация в&nbsp;одноранговой сети не&nbsp;предусмотрена. Интерфейсы же&nbsp;приложений, тем&nbsp;более если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутентификации. Открываем сокет.... И&nbsp;там уже&nbsp;что ни&nbsp;попадя... <a name="texnologii.openssl" href="http://freesource.info/wiki/Texnologii/OpenSSL&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;SSL">SSL</a>, HTTPS, <a name="texnologii.openid" href="http://freesource.info/wiki/Texnologii/OpenID&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;ID">OpenID</a>, Kerberos, ...</div><br /> <b>Удалено:</b><br /> <div class="deletions">У&nbsp;современных систем средства класса IPC&nbsp;(в классическом случае это&nbsp;каналы и&nbsp;параметры, переданные приложению как&nbsp;подстановка строки выданной другим приложением) имеют тенденцию объединяться с&nbsp;RPC. Конечно, сетевое взаимодействие можно также представить в&nbsp;виде взаимодействия приложений передающих команды через параметры коммандной строки и&nbsp;каналы. Но&nbsp;так нигде не&nbsp;сделано. Во-первых это&nbsp;связано с&nbsp;проблемами безопасности и&nbsp;сетевой аутентификацией, во-вторых &ndash; с&nbsp;необходимостью адекватной авторизации, где&nbsp;немаловажную роль играют идентификторы (aka uid&nbsp;и&nbsp;gid). <br /> Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;их удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix роль среды для&nbsp;сессии выполняет называемая оболочка или&nbsp;коммандный интерпретатор. Эта&nbsp;сессия запускается тв&nbsp;или иначе в&nbsp;виде процесса, кторому присваивается соотвествующий идентификатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли... <br /> Например воьзмём ещё одну простую задачу &ndash; обратиться от&nbsp;имени пользователя к&nbsp;локальному сервису. Что&nbsp;для этого существует?<br /> Последние два&nbsp;находятся на&nbsp;файловой системе и&nbsp;для работы с&nbsp;ними требуется каким-либо образом передать клиенту имя&nbsp;файла для&nbsp;обращения к&nbsp;сервису. Для&nbsp;этого обычно используются, например в&nbsp;D-BUS, переменные окружения или&nbsp;файлы настройки в&nbsp;домашнем каталоге. В&nbsp;первом случае, чтобы клиент мог&nbsp;воспользоваться таким сервисом, этот сервис должен быть запущен до&nbsp;запуска его&nbsp;клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана соотвествующая переменная окружения. Во&nbsp;втором же&nbsp;случае, должен существовать либо путь, вычисляемый по&nbsp;умолчанию, либо отдельная настройка под&nbsp;каждого клиента. В&nbsp;любом случае, при&nbsp;использовании файлов, авторизовывать клиента целесообразно только на&nbsp;уровне доступа к&nbsp;этому файлу (с помощью группы или&nbsp;ACL), что&nbsp;означает необходимость создания разных файлов для&nbsp;разных клиентов, чтобы отличать их&nbsp;друг от&nbsp;друга. В&nbsp;самом удачном варианте это&nbsp;требует создания сложной инфраструктуры для&nbsp;поддержки этого механизма. Если таких служб станет много, то&nbsp;без шаблонов привилегий тут&nbsp;не&nbsp;обойтись... Одним из&nbsp;вариантов стандартизации на&nbsp;этом уровне является связка HAL/D-BUS/PolicyKit<br /> Основную мысль рассуждения, хотелось бы&nbsp;завершить следующим резюме. Пока не&nbsp;будет придумана и&nbsp;реализована общая схема интеграции IPC&nbsp;и&nbsp;RPC, пока не&nbsp;будут организованы стандарные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути к&nbsp;современным корпоративным средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим. Это&nbsp;уже сейчас почти так...<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него аппелируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у MIT. Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же&nbsp;даёт Kerberos? Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть даже такой термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартного PAM&nbsp;требует ввода пароля &#8220;by design&#8221;. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что&nbsp;одноранговых сетях омжно заменить на&nbsp;Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть кербризация в&nbsp;одноранговой сети не&nbsp;предусмотрена. Интерфейсы же&nbsp;приложений, тем&nbsp;более если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутентификации. Открываем сокет.... И&nbsp;там уже&nbsp;что ни&nbsp;поподя... <a href="http://freesource.info/wiki/Texnologii/OpenSSL&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;SSL">SSL</a>, HTTPS, <a href="http://freesource.info/wiki/Texnologii/OpenID&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;ID">OpenID</a>, Kerberos, ...</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-15+04%3A55%3A22 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-15+04%3A55%3A22">2008-02-15 04:55:22</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-15+04%3A59%3A58">2008-02-15 04:59:58</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;их удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix роль среды для&nbsp;сессии выполняет называемая оболочка или&nbsp;коммандный интерпретатор. Эта&nbsp;сессия запускается тв&nbsp;или иначе в&nbsp;виде процесса, кторому присваивается соотвествующий идентификатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли...</div><br /> <b>Удалено:</b><br /> <div class="deletions">Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;их удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix это&nbsp;так называемая или&nbsp;коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли...</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-11+03%3A24%3A20 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-11+03%3A24%3A20">2008-02-11 03:24:20</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-15+04%3A55%3A22">2008-02-15 04:55:22</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;их удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix это&nbsp;так называемая или&nbsp;коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли...</div><br /> <b>Удалено:</b><br /> <div class="deletions">Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа не&nbsp;может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix это&nbsp;так называемая или&nbsp;коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли...</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-10+20%3A56%3A45 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+20%3A56%3A45">2008-02-10 20:56:45</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-11+03%3A24%3A20">2008-02-11 03:24:20</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Основной целью этой статьи является прояснение технических проблем использования <a name="stat_jaklassicheskijjunixway" href="http://freesource.info/wiki/Stat'jaKlassicheskijjUnixWay&" class="" title="Статья&nbsp;Классический&nbsp;Unix&nbsp;Way">классического Unix Way</a> на&nbsp;практике. Первый вариант этой статьи был&nbsp;написан как&nbsp;комментарий к&nbsp;статье <a name="ideologijalinux" href="http://freesource.info/wiki/IdeologijaLinux&" class="" title="Идеология&nbsp;Linux">идеология Linux</a> в&nbsp;отношении к&nbsp;части о&nbsp;проявлении вреда (Free|Open)Source. К&nbsp;сожалению, комментарий канул в&nbsp;лету, но&nbsp;его копия чудом сохранилась.</div><br /> <b>Удалено:</b><br /> <div class="deletions">Основной целью этой статьи является прояснение технических проблем использования (<a href="http://freesource.info/wiki/Stat'jaKlassicheskijjUnixWay&" class="">Статья&nbsp;Классический&nbsp;Unix&nbsp;Way</a> классического Unix Way)) на&nbsp;практике. Первый вариант этой статьи был&nbsp;написан как&nbsp;комментарий к&nbsp;статье <a href="http://freesource.info/wiki/IdeologijaLinux&" class="" title="Идеология&nbsp;Linux">идеология Linux</a> в&nbsp;отношении к&nbsp;части о&nbsp;проявлении вреда (Free|Open)Source. К&nbsp;сожалению, комментарий канул в&nbsp;лету, но&nbsp;его копия чудом сохранилась.</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-10+20%3A52%3A22 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+20%3A52%3A22">2008-02-10 20:52:22</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+20%3A56%3A45">2008-02-10 20:56:45</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Основной целью этой статьи является прояснение технических проблем использования (<a href="http://freesource.info/wiki/Stat'jaKlassicheskijjUnixWay&" class="">Статья&nbsp;Классический&nbsp;Unix&nbsp;Way</a> классического Unix Way)) на&nbsp;практике. Первый вариант этой статьи был&nbsp;написан как&nbsp;комментарий к&nbsp;статье <a href="http://freesource.info/wiki/IdeologijaLinux&" class="" title="Идеология&nbsp;Linux">идеология Linux</a> в&nbsp;отношении к&nbsp;части о&nbsp;проявлении вреда (Free|Open)Source. К&nbsp;сожалению, комментарий канул в&nbsp;лету, но&nbsp;его копия чудом сохранилась.<br /> У&nbsp;современных систем средства класса IPC&nbsp;(в классическом случае это&nbsp;каналы и&nbsp;параметры, переданные приложению как&nbsp;подстановка строки выданной другим приложением) имеют тенденцию объединяться с&nbsp;RPC. Конечно, сетевое взаимодействие можно также представить в&nbsp;виде взаимодействия приложений передающих команды через параметры коммандной строки и&nbsp;каналы. Но&nbsp;так нигде не&nbsp;сделано. Во-первых это&nbsp;связано с&nbsp;проблемами безопасности и&nbsp;сетевой аутентификацией, во-вторых &ndash; с&nbsp;необходимостью адекватной авторизации, где&nbsp;немаловажную роль играют идентификторы (aka uid&nbsp;и&nbsp;gid). <br /> Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа не&nbsp;может быть запущена вне&nbsp;рамок локального процесса. А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix это&nbsp;так называемая или&nbsp;коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация. Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста. Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у&nbsp;супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы. Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли... <br /> Последние два&nbsp;находятся на&nbsp;файловой системе и&nbsp;для работы с&nbsp;ними требуется каким-либо образом передать клиенту имя&nbsp;файла для&nbsp;обращения к&nbsp;сервису. Для&nbsp;этого обычно используются, например в&nbsp;D-BUS, переменные окружения или&nbsp;файлы настройки в&nbsp;домашнем каталоге. В&nbsp;первом случае, чтобы клиент мог&nbsp;воспользоваться таким сервисом, этот сервис должен быть запущен до&nbsp;запуска его&nbsp;клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана соотвествующая переменная окружения. Во&nbsp;втором же&nbsp;случае, должен существовать либо путь, вычисляемый по&nbsp;умолчанию, либо отдельная настройка под&nbsp;каждого клиента. В&nbsp;любом случае, при&nbsp;использовании файлов, авторизовывать клиента целесообразно только на&nbsp;уровне доступа к&nbsp;этому файлу (с помощью группы или&nbsp;ACL), что&nbsp;означает необходимость создания разных файлов для&nbsp;разных клиентов, чтобы отличать их&nbsp;друг от&nbsp;друга. В&nbsp;самом удачном варианте это&nbsp;требует создания сложной инфраструктуры для&nbsp;поддержки этого механизма. Если таких служб станет много, то&nbsp;без шаблонов привилегий тут&nbsp;не&nbsp;обойтись... Одним из&nbsp;вариантов стандартизации на&nbsp;этом уровне является связка HAL/D-BUS/PolicyKit<br /> Тем&nbsp;не&nbsp;менее, в&nbsp;своём большинстве, в&nbsp;силу необходимости удалённого управления, большинство решений, например mpd, работают с&nbsp;помощью сокетов. И&nbsp;тут возникает весьма не&nbsp;простая вещь. Возникает новый класс сетевых пользователей, даже если эти&nbsp;пользователи на&nbsp;самом деле локальные. Любая задача вида:<br /> требует отдельной аутентификации... В&nbsp;самом небезопасном случае, это&nbsp;означает, что&nbsp;по&nbsp;домашнему каталогу пользователя и&nbsp;по /etc начинают расползаться вбитые пароли. А&nbsp;что если пароль измениться? Его&nbsp;придётся изменять у&nbsp;всех клиентов. Кроме того это&nbsp;не&nbsp;удобно для&nbsp;сервера &ndash; у&nbsp;него нет&nbsp;стандартного средства кроме PAM, и&nbsp;он вынужден каждый раз&nbsp;требовать пароль.<br /> Многие задачи, как&nbsp;в&nbsp;показанном в&nbsp;начале примере, решаются поверх протокола SSH, но&nbsp;полноценный RPC&nbsp;на&nbsp;нём сделать не&nbsp;просто, поскольку он&nbsp;не предназначен для&nbsp;решения всего спектра задач необходимых при&nbsp;удалённом управлении. Прежде всего потому, что&nbsp;спроектирован как&nbsp;удалённая консоль и&nbsp;для использования системными службами не&nbsp;предназначен. <br /> Связи между реализациями классического Unix Way&nbsp;и&nbsp;современными задачами, требующими сетевой аутентификации и&nbsp;авторизации нет. Именно это&nbsp;мешает сделать простым запуск команды на&nbsp;удалённом хосте. Отсутствие этой связи можно проследить отсутствием связи между отдельными подсистемами ядра, поскольку именно на&nbsp;уровне ядра происходит распределение полномочий процессов. Сетевая аутентификация и&nbsp;авторизация никак на&nbsp;вписывается в&nbsp;Unix Way, поскольку реализуется на&nbsp;прикладном уровне. Здесь ещё не&nbsp;хватает сетевой файловой системы и&nbsp;соответствия между uid'ами и&nbsp;gid'ами на&nbsp;локальном и&nbsp;удалённом хостах. Это&nbsp;тоже не&nbsp;вписывается в&nbsp;текущие реализации классического Unix Way.<br /> Основную мысль рассуждения, хотелось бы&nbsp;завершить следующим резюме. Пока не&nbsp;будет придумана и&nbsp;реализована общая схема интеграции IPC&nbsp;и&nbsp;RPC, пока не&nbsp;будут организованы стандарные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути к&nbsp;современным корпоративным средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим. Это&nbsp;уже сейчас почти так...<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него аппелируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у MIT. Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же&nbsp;даёт Kerberos? Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть даже такой термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартного PAM&nbsp;требует ввода пароля &#8220;by design&#8221;. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что&nbsp;одноранговых сетях омжно заменить на&nbsp;Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть кербризация в&nbsp;одноранговой сети не&nbsp;предусмотрена. Интерфейсы же&nbsp;приложений, тем&nbsp;более если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутентификации. Открываем сокет.... И&nbsp;там уже&nbsp;что ни&nbsp;поподя... <a href="http://freesource.info/wiki/Texnologii/OpenSSL&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;SSL">SSL</a>, HTTPS, <a href="http://freesource.info/wiki/Texnologii/OpenID&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;ID">OpenID</a>, Kerberos, ...</div><br /> <b>Удалено:</b><br /> <div class="deletions">Основной целью этой статьи является прояснение технических проблем использования <a href="http://freesource.info/wiki/Stat'jaKlassicheskijjUnixWay&" class="" title="Статья&nbsp;Классический&nbsp;Unix&nbsp;Way">классического Unix Way</a> на&nbsp;практике.<br /> Первый вариант этой статьи был&nbsp;написан как&nbsp;комментарий к&nbsp;статье <a href="http://freesource.info/wiki/IdeologijaLinux&" class="" title="Идеология&nbsp;Linux">идеология Linux</a> в&nbsp;отношении к&nbsp;части о&nbsp;проявлении вреда (Free|Open)Source.<br /> К&nbsp;сожалению, комментарий канул в&nbsp;лету, но&nbsp;его копия чудом сохранилась.<br /> У&nbsp;современных систем средства класса IPC&nbsp;(в классическом случае это&nbsp;каналы и&nbsp;параметры, переданные приложению как&nbsp;подстановка строки выданной другим приложением)<br /> имеют тенденцию объединяться с&nbsp;RPC. Конечно, сетевое взаимодействие можно также представить в&nbsp;виде взаимодействия приложений передающих команды через параметры<br /> коммандной строки и&nbsp;каналы. Но&nbsp;так нигде не&nbsp;сделано. Во-первых это&nbsp;связано с&nbsp;проблемами безопасности и&nbsp;сетевой аутентификацией, во-вторых &ndash; с&nbsp;необходимостью адекватной<br /> авторизации, где&nbsp;немаловажную роль играют идентификторы (aka uid&nbsp;и&nbsp;gid). <br /> Из&nbsp;основных свойств архитектуры Unix, следует, классический unix-way не&nbsp;предполагает, что&nbsp;программа не&nbsp;может быть запущена вне&nbsp;рамок локального процесса.<br /> А&nbsp;это означает, невозможность запуска команды или&nbsp;серии комманд и&nbsp;удалённого выполнения. А&nbsp;если таких задач становится много? Некоторые решаются и&nbsp;создают<br /> свои велосипеды или&nbsp;протоколы, но&nbsp;обычно над&nbsp;этим никто не&nbsp;задумывается до&nbsp;самого последнего момента. Природа запуска приложений в&nbsp;Unix такова, что&nbsp;аутентификация<br /> тесно связана идентификатором пользователя от&nbsp;имени которого выполняются все&nbsp;приложения в&nbsp;рамках сессии. Для&nbsp;типичных команд в&nbsp;Unix это&nbsp;так называемая или<br /> коммандный интерпретатор. Именно этот идентификатор определяет права пользователя в&nbsp;локальной системе, для&nbsp;удалённого же&nbsp;хоста требуется сетевая аутетнификация.<br /> Вообще тема сетевой аутентификации &ndash; это&nbsp;сложная и&nbsp;запутанная вещь. Чтобы в&nbsp;неё вникнуть нужно осознать как&nbsp;работает локальная. А&nbsp;локальная же&nbsp;работает достаточно<br /> просто. При&nbsp;входе в&nbsp;систему, на&nbsp;основании удачного завершения действия auth, правильно скофигурированных модулей <a href="http://freesource.info/wiki/Texnologii/PAM&" class="" title="Технологии&nbsp;/&nbsp;PAM">PAM</a>, родительскому процессу пользователя назначаются идентификаторы пользователя (uid) и&nbsp;группы (gid). Далее это&nbsp;сохраняетя на&nbsp;время всей сессии и&nbsp;аутентификация проводится ядром прозрачно на&nbsp;уровне локального хоста.<br /> Важным моментов является выделение нескольких видов идентификаторов, в&nbsp;общем виде назовём их&nbsp;по эффективными. Права на&nbsp;смену этих идентификаторов есть только у<br /> супер-пользоателя. В&nbsp;этом плане существует ещё большая проблема. Авторизоваться в&nbsp;Unix Way&nbsp;стандартными методами ядра возможна только посредством файловой системы.<br /> Всё остальное &ndash; это&nbsp;надстройки и&nbsp;костыли... <br /> Последние два&nbsp;находятся на&nbsp;файловой системе и&nbsp;для работы с&nbsp;ними требуется каким-либо образом передать клиенту имя&nbsp;файла для&nbsp;обращения к&nbsp;сервису. Для&nbsp;этого<br /> обычно используются, например в&nbsp;D-BUS, переменные окружения или&nbsp;файлы настройки в&nbsp;домашнем каталоге. В&nbsp;первом случае, чтобы клиент мог&nbsp;воспользоваться<br /> таким сервисом, этот сервис должен быть запущен до&nbsp;запуска его&nbsp;клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана<br /> соотвествующая переменная окружения. Во&nbsp;втором же&nbsp;случае, должен существовать либо путь, вычисляемый по&nbsp;умолчанию, либо отдельная настройка под&nbsp;каждого<br /> клиента. В&nbsp;любом случае, при&nbsp;использовании файлов, авторизовывать клиента целесообразно только на&nbsp;уровне доступа к&nbsp;этому файлу (с помощью группы или&nbsp;ACL),<br /> что&nbsp;означает необходимость создания разных файлов для&nbsp;разных клиентов, чтобы отличать их&nbsp;друг от&nbsp;друга.<br /> В&nbsp;самом удачном варианте это&nbsp;требует создания сложной инфраструктуры для&nbsp;поддержки этого механизма. Если таких служб станет много, то&nbsp;без шаблонов<br /> привилегий тут&nbsp;не&nbsp;обойтись... Одним из&nbsp;вариантов стандартизации на&nbsp;этом уровне является связка HAL/D-BUS/PolicyKit<br /> Тем&nbsp;не&nbsp;менее, в&nbsp;своём большинстве, в&nbsp;силу необходимости удалённого управления, большинство решений, например mpd, работают с&nbsp;помощью сокетов. И&nbsp;тут возникает<br /> весьма не&nbsp;простая вещь. Возникает новый класс сетевых пользователей, даже если эти&nbsp;пользователи на&nbsp;самом деле локальные. Любая задача вида:<br /> требует отдельной аутентификации... В&nbsp;самом небезопасном случае, это&nbsp;означает, что&nbsp;по&nbsp;домашнему каталогу пользователя и&nbsp;по /etc начинают расползаться вбитые пароли.<br /> А&nbsp;что если пароль измениться? Его&nbsp;придётся изменять у&nbsp;всех клиентов. Кроме того это&nbsp;не&nbsp;удобно для&nbsp;сервера &ndash; у&nbsp;него нет&nbsp;стандартного средства кроме PAM, и&nbsp;он вынужден<br /> каждый раз&nbsp;требовать пароль.<br /> Многие задачи, как&nbsp;в&nbsp;показанном в&nbsp;начале примере, решаются поверх протокола SSH, но&nbsp;полноценный RPC&nbsp;на&nbsp;нём сделать не&nbsp;просто, поскольку он&nbsp;не предназначен для&nbsp;решения<br /> всего спектра задач необходимых при&nbsp;удалённом управлении. Прежде всего потому, что&nbsp;спроектирован как&nbsp;удалённая консоль и&nbsp;для использования системными службами не<br /> предназначен. <br /> Связи между реализациями классического Unix Way&nbsp;и&nbsp;современными задачами, требующими сетевой аутентификации и&nbsp;авторизации нет. Именно это&nbsp;мешает сделать простым запуск команды на&nbsp;удалённом хосте. Отсутствие этой связи можно проследить отсутствием связи между отдельными подсистемами ядра, поскольку именно на&nbsp;уровне ядра происходит распределение полномочий<br /> процессов. Сетевая аутентификация и&nbsp;авторизация никак на&nbsp;вписывается в&nbsp;Unix Way, поскольку реализуется на&nbsp;прикладном уровне. Здесь ещё не&nbsp;хватает сетевой файловой системы и&nbsp;соответствия<br /> между uid'ами и&nbsp;gid'ами на&nbsp;локальном и&nbsp;удалённом хостах. Это&nbsp;тоже не&nbsp;вписывается в&nbsp;текущие реализации классического Unix Way.<br /> Основную мысль рассуждения, хотелось бы&nbsp;завершить следующим резюме. Пока не&nbsp;будет придумана и&nbsp;реализована общая схема интеграции IPC&nbsp;и&nbsp;RPC,<br /> пока не&nbsp;будут организованы стандарные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути к&nbsp;современным корпоративным<br /> средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим.<br /> Это&nbsp;уже сейчас почти так...<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него аппелируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у MIT.<br /> Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же&nbsp;даёт Kerberos?<br /> Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть даже такой<br /> термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартного PAM<br /> требует ввода пароля &#8220;by design&#8221;. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что<br /> одноранговых сетях омжно заменить на&nbsp;Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме<br /> того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть кербризация в&nbsp;одноранговой сети не&nbsp;предусмотрена. Интерфейсы же&nbsp;приложений, тем&nbsp;более<br /> если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутентификации. Открываем сокет....<br /> И&nbsp;там уже&nbsp;что ни&nbsp;поподя... <a href="http://freesource.info/wiki/Texnologii/OpenSSL&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;SSL">SSL</a>, HTTPS, <a href="http://freesource.info/wiki/Texnologii/OpenID&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;ID">OpenID</a>, Kerberos, ...</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-10+09%3A42%3A45 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+09%3A42%3A45">2008-02-10 09:42:45</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+20%3A52%3A22">2008-02-10 20:52:22</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions"><ol type="3"><li> Файл сокета</li></ol> обычно используются, например в&nbsp;D-BUS, переменные окружения или&nbsp;файлы настройки в&nbsp;домашнем каталоге. В&nbsp;первом случае, чтобы клиент мог&nbsp;воспользоваться<br /> таким сервисом, этот сервис должен быть запущен до&nbsp;запуска его&nbsp;клиентов, чтобы родительскому процессу всего дерева процессов клиента могла быть передана<br /> соотвествующая переменная окружения. Во&nbsp;втором же&nbsp;случае, должен существовать либо путь, вычисляемый по&nbsp;умолчанию, либо отдельная настройка под&nbsp;каждого<br /> клиента. В&nbsp;любом случае, при&nbsp;использовании файлов, авторизовывать клиента целесообразно только на&nbsp;уровне доступа к&nbsp;этому файлу (с помощью группы или&nbsp;ACL),<br /> что&nbsp;означает необходимость создания разных файлов для&nbsp;разных клиентов, чтобы отличать их&nbsp;друг от&nbsp;друга.<br /> В&nbsp;самом удачном варианте это&nbsp;требует создания сложной инфраструктуры для&nbsp;поддержки этого механизма. Если таких служб станет много, то&nbsp;без шаблонов<br /> привилегий тут&nbsp;не&nbsp;обойтись... Одним из&nbsp;вариантов стандартизации на&nbsp;этом уровне является связка HAL/D-BUS/PolicyKit<br /> требует отдельной аутентификации... В&nbsp;самом небезопасном случае, это&nbsp;означает, что&nbsp;по&nbsp;домашнему каталогу пользователя и&nbsp;по /etc начинают расползаться вбитые пароли.<a name="h8270-1"></a><h2> Следствия </h2> Многие задачи, как&nbsp;в&nbsp;показанном в&nbsp;начале примере, решаются поверх протокола SSH, но&nbsp;полноценный RPC&nbsp;на&nbsp;нём сделать не&nbsp;просто, поскольку он&nbsp;не предназначен для&nbsp;решения<br /> всего спектра задач необходимых при&nbsp;удалённом управлении. Прежде всего потому, что&nbsp;спроектирован как&nbsp;удалённая консоль и&nbsp;для использования системными службами не<br /> предназначен. <br /> Связи между реализациями классического Unix Way&nbsp;и&nbsp;современными задачами, требующими сетевой аутентификации и&nbsp;авторизации нет. Именно это&nbsp;мешает сделать простым запуск команды на&nbsp;удалённом хосте. Отсутствие этой связи можно проследить отсутствием связи между отдельными подсистемами ядра, поскольку именно на&nbsp;уровне ядра происходит распределение полномочий<br /> процессов. Сетевая аутентификация и&nbsp;авторизация никак на&nbsp;вписывается в&nbsp;Unix Way, поскольку реализуется на&nbsp;прикладном уровне. Здесь ещё не&nbsp;хватает сетевой файловой системы и&nbsp;соответствия<br /> между uid'ами и&nbsp;gid'ами на&nbsp;локальном и&nbsp;удалённом хостах. Это&nbsp;тоже не&nbsp;вписывается в&nbsp;текущие реализации классического Unix Way.<br /> Основную мысль рассуждения, хотелось бы&nbsp;завершить следующим резюме. Пока не&nbsp;будет придумана и&nbsp;реализована общая схема интеграции IPC&nbsp;и&nbsp;RPC,<br /> пока не&nbsp;будут организованы стандарные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути к&nbsp;современным корпоративным<br /> средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим.<br /> требует ввода пароля &#8220;by design&#8221;. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что<br /> одноранговых сетях омжно заменить на&nbsp;Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме</div><br /> <b>Удалено:</b><br /> <div class="deletions"><ol type="3"><li> Файл сокета</li></ol> обычно используются, например в&nbsp;D-BUS, переменные окружения. То&nbsp;есть, что&nbsp;бы&nbsp;клиент мог&nbsp;им&nbsp;воспользоваться сервис должен быть запущен до&nbsp;клиента и&nbsp;родительскому<br /> процессу всего дерева процессов пользователя должна быть передана соотвествующая переменная окружения. С&nbsp;другой стороны это&nbsp;может быть файл в&nbsp;домашнем<br /> каталоге пользователя. Но&nbsp;тогда возникает вопрос о&nbsp;том, как&nbsp;быть, если сервис запущен не&nbsp;от имени пользователя. Вероятно с&nbsp;помощью ACL&nbsp;или группы.<br /> И&nbsp;то и&nbsp;другое требует действий администратора как&nbsp;во&nbsp;время настройки, так&nbsp;и&nbsp;во время добавления новых пользователей. Если таких служб станет много, то&nbsp;без<br /> шаблонов привилегий тут&nbsp;не&nbsp;обойтись...<br /> требует отдельной аутентификации... В&nbsp;самом небезопасном случае, это&nbsp;означает, что&nbsp;по&nbsp;домашнему каталогу пользователя и&nbsp;по /etc/ начинают расползаться вбитые пароли.<br /> Что&nbsp;же&nbsp;здесь ещё не&nbsp;учтено... Ага&nbsp;здесь ещё не&nbsp;хватает сетевой файловой системы. И&nbsp;соответствия между uid'ами и&nbsp;gid'ами на&nbsp;локальном и&nbsp;удалённом хостах.<br /> Вроде всё из&nbsp;основных проблем... Если вы&nbsp;ещё не&nbsp;потеряли мысль рассуждения, то&nbsp;завершить его&nbsp;хотелось бы&nbsp;следующим. Пока не&nbsp;будет придумана и&nbsp;реализована<br /> общая схема интеграции IPC&nbsp;и&nbsp;RPC, пока не&nbsp;будут орагнизованы стандарные средства и&nbsp;API для&nbsp;единой и&nbsp;прозрачной сетевой и&nbsp;локальной аутентификации, пути<br /> к&nbsp;современным корпоративным средам у&nbsp;Unix Way&nbsp;нет. К&nbsp;сожалению, к&nbsp;моменту когда они&nbsp;будут реализованы, всё уже&nbsp;тоже может оказаться слишком далеко ушедшим.<br /> требует ввода пароля. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что<br /> одноранговых сетях заменяется сейчас Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-10+09%3A30%3A59 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+09%3A30%3A59">2008-02-10 09:30:59</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+09%3A42%3A45">2008-02-10 09:42:45</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">процессу всего дерева процессов пользователя должна быть передана соотвествующая переменная окружения. С&nbsp;другой стороны это&nbsp;может быть файл в&nbsp;домашнем<br /> каталоге пользователя. Но&nbsp;тогда возникает вопрос о&nbsp;том, как&nbsp;быть, если сервис запущен не&nbsp;от имени пользователя. Вероятно с&nbsp;помощью ACL&nbsp;или группы.<br /> И&nbsp;то и&nbsp;другое требует действий администратора как&nbsp;во&nbsp;время настройки, так&nbsp;и&nbsp;во время добавления новых пользователей. Если таких служб станет много, то&nbsp;без<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него аппелируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у MIT.<br /> Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же&nbsp;даёт Kerberos?<br /> Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть даже такой<br /> термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартного PAM<br /> требует ввода пароля. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, что<br /> одноранговых сетях заменяется сейчас Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... Кроме<br /> того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть кербризация в&nbsp;одноранговой сети не&nbsp;предусмотрена. Интерфейсы же&nbsp;приложений, тем&nbsp;более<br /> если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутентификации. Открываем сокет....<br /> И&nbsp;там уже&nbsp;что ни&nbsp;поподя... <a href="http://freesource.info/wiki/Texnologii/OpenSSL&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;SSL">SSL</a>, HTTPS, <a href="http://freesource.info/wiki/Texnologii/OpenID&" class="" title="Технологии&nbsp;/&nbsp;Open&nbsp;ID">OpenID</a>, Kerberos, ...</div><br /> <b>Удалено:</b><br /> <div class="deletions">процессу всего дерева процессов пользователя должна быть передана соотвествующая переменная окружения. С&nbsp;другой стороны это&nbsp;может быть файл в&nbsp;д<br /> омашнем каталоге пользователя. Но&nbsp;тогда возникает вопрос о&nbsp;том, как&nbsp;быть, если сервис запущен не&nbsp;от имени пользователя. Вероятно с&nbsp;помощью ACL&nbsp;или групп<br /> ы. И&nbsp;то и&nbsp;другое требует действий администратора как&nbsp;во&nbsp;время настройки, так&nbsp;и&nbsp;во время добавления новых пользователей. Если таких служб станет много, то&nbsp;без<br /> На&nbsp;самом деле всё уже&nbsp;есть. Есть Kerberos и&nbsp;именно он&nbsp;используется в&nbsp;w2k3, и&nbsp;именно про&nbsp;него аппелируют к&nbsp;MIT. Хотя в&nbsp;w2k3 он&nbsp;не совсем такой, какой он&nbsp;у<br /> MIT. Он&nbsp;использует некоторые поля, которые в&nbsp;стандарте можно использовать для&nbsp;своих целей разработчикам, для&nbsp;передачи авторизационной информации. Что&nbsp;же<br /> даёт Kerberos? Он&nbsp;даёт необходимую прозрачную сетевую аутентификацию. Почему же&nbsp;он не&nbsp;используется повсеместно? Потому, что&nbsp;усложняет программы (есть да<br /> же&nbsp;такой термин керберизация). Керберизация означает однозначное завязывание на&nbsp;одну библиотеку и&nbsp;один вариант аутентификации, а&nbsp;использование стандартно<br /> го&nbsp;PAM требует ввода пароля. Есть попытка сделать более стандартную обёртку &ndash; GSSAPI. К&nbsp;сожалению, эта&nbsp;обёртка на&nbsp;практике очень капризна (требует DNS, ч<br /> то&nbsp;в одноранговых сетях заменяется сейчас Avahi) &ndash; многие разработчики и&nbsp;администраторы её не&nbsp;очень жалуют, хотя за&nbsp;всех сказать конечно не&nbsp;возьмусь... К<br /> роме того Kerberos требует выделенного сервера &ndash; KDC, то&nbsp;есть кербризация в&nbsp;одноранговой сети не&nbsp;предусмотрена.<br /> Интерфейсы же&nbsp;приложений, тем&nbsp;более если они&nbsp;сетевые, могут быть любыми удобными, поскольку никакой unix-way не&nbsp;решает вопроса глобальной сетевой аутенти<br /> фикации. Открываем сокет.... И&nbsp;там уже&nbsp;что ни&nbsp;поподя... SSL, HTTPS, <span class="missingpage">Open&nbsp;ID</span><a href="http://freesource.info/wiki/OpenID/edit?add=1&" title="Создать эту страницу">?</a>, Kerberos, ...</div></div> http://freesource.info/wiki/NotUnixWay/show?time=2008-02-10+09%3A28%3A33 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/NotUnixWay&" class="">/Not&nbsp;Unix&nbsp;Way</a> за <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+09%3A28%3A33">2008-02-10 09:28:33</a> и <a href="http://freesource.info/wiki/NotUnixWay?time=2008-02-10+09%3A30%3A59">2008-02-10 09:30:59</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions"><ul><li> <a href="http://gazette.linux.ru.net/rus/articles/gariki.html" target="_blank" title="Внешняя ссылка (откроется в новом окне)" class="outerlink"><img src="http://freesource.info/wiki/themes/coffee/icons/web.gif" alt="" border="0" />Linux Gazzete about Unix Way</a></li></ul></div><br /> <b>Удалено:</b><br /> <div class="deletions"><ul><li> ((<a href="http://gazette.linux.ru.net/rus/articles/gariki.html" target="_blank" title="Внешняя ссылка (откроется в новом окне)" class="outerlink"><img src="http://freesource.info/wiki/themes/coffee/icons/web.gif" alt="" border="0" />http://gazette.linux.ru.net/rus/articles/gariki.html</a> ))</li></ul></div></div>