|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 20 Jun 2000 20:40:33
To : Nick A. Leuta
Subject : Re: Hа: Hа: Hа: Hа: Hа: Hа: uucpd and PAM
--------------------------------------------------------------------------------
Hello Nick A. Leuta!
>> Я-то думал, что имеется в виду netinfo или NIS+, а вон оно что. ;(
>> Тогда завеpяю Вас, что что-то Вы не понимаете в идеологии - потому что
>> nsswitch есть не сpедство, а всего лишь полуметаидея-полуидеология,
>> несмотpя на то, что оно офоpмляется отдельным конфигом.
NAL> Hу, как самостоятельное средство оно и не требуется :-) Оно нужно для того,
NAL> чтобы унифицировать способ взятия откуда-нибудь исходных данных для
NAL> последующей отдачей их функциями вида getpw*() (getpwnam(), напр),
NAL> getserv*() (getservent(), напр.), getproto*(), ether*() и т.п.
NAL> чтобы приложение не парсило самостоятельно всякие там /etc/* типа passwd,
NAL> master.passwd/shadow, networks, protocols и т.п., чтобы при необходимости
NAL> можно было правкой библиотечных функций изменить источник информации,
NAL> хранящейся в этих файлах. А NSS доводит эту идею до логического конца,
NAL> исключая необходимость править сами библиотечные функции, а вместо этого
NAL> править конфиг: надо - используем NIS/NIS+, надо - локальные файлы, надо -
NAL> LDAP, а хоть и все сразу, а можно и без чего-нить из этого...
Ага, как же, как же. И как Вы умудритесь в libc, которая в жизни не умела LDAP,
вдруг дать ей это умение одним приказом в nsswitch.conf? Рожденный ползать
получил приказ летать?
>> И к паму оно как бы совеpшенно оpтогонально ;)
NAL> Каждый по отдельности - действительно самостоятельны, и действительно
NAL> неполноценны: PAM не может дать соответствия login<->UID, а NSS далеко не
NAL> всегда может вытащить пароль (далеко не всякая аутентификационная система
NAL> может его отдать, либо потому, что не может, либо даже может, вот только
NAL> кодирован он не так, так это ожидается от значения, возвращаемого
NAL> getpwent() ). Hо вот вместе (систему не равна сумме компонентов :-) ) они
NAL> полностью справляются с задачей аутентификации, и даже больше:
NAL> аутентификационная логика в приложении сводится к минимуму, а что
NAL> происходит в процессе аутентификации, зависит только от фантазии сисадмина
NAL> и авторов pam_* модулей: например, можно давать/отказывать в доступе в
NAL> зависимости от фазы луны (ибо она неплохо рассчитывается).
Как только доходит до реалий, в дело вступают грязные хаки.
Мне пофиг, какой идиот придумал PAM - у него совершенно кривые и извращенные
отношения между AAA&S. Да, он решает задачу - частично - вынесением
части этих операций в отдельные блоки. Hо точно так же это можно было устроить
и силами самого приложения - как оно часто и делается безо всякого пама.
Я понимаю, почему в *BSD его (пама) мало: тошнит-с.
>> Как бы засовывать тех же юзеpов в LDAP - ну совеpшенно неудобно.
NAL> А рулить локальными юзерами на десятке машин удобнее?
А при чем тут LDAP? Если бы был упомянут NIS+, я бы еще поверил.
>> И надо патчить ту же libc (g- или нет - пофиг) на эту тему ну совсем
>> не pадует...
NAL> Патчить фрюшные библиотеки (или портировать glibc (где nss и живет,
NAL> собственно) на FreeBSD)? Тут легким патчем не обойтись - задача достаточно
NAL> серьезная.
/me rotfl. NSS именно как _N_SS во фряхе давно есть. man host.conf.
Остальное - то, что нужно и то, что реализуемо нормальными средствами - тоже
есть. Пусть и без уродского /etc/nsswitch.conf.
А своими идеями про портирования glibc на фряху Вы мне кое-что напомнили.
Про то, как Debian'овцы решили осчастливить светом Единственно Верного Учения
GNU несчастных моральных уродов из BSD world. Так оно и заглохло, потому что
не смогли решить - делать FreeBSD kernel + glibc или Linux kernel + BSD libc...
NAL> К тому же просто прикручивать nss ради nss смысла мало, надо еще
NAL> и pam, а значить и изрядное количество стандартных утилит тоже править...
NAL> Плюс еще о портах не забыть...
Вот именно. А так как PAM по себе тоже никому толком не нужен, потому что
убог и крив, то зачем вообще заниматься именно ими? Проблем и так хватает.
... Потом уволил одного, и стало их FF
-- --
Valentin Nechayev
netch@carrier.kiev.ua
II:LDXIII/DCCCLXXIII.CCC
--- ifmail v.2.15dev5
* Origin: Lucky Netch Incorporated (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
