|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Nick A. Leuta 2:5020/400 20 Jun 2000 19:44:07
To : All
Subject : Hа: Hа: Hа: Hа: Hа: Hа: uucpd and PAM
--------------------------------------------------------------------------------
"Valentin Nechayev" <nx@nn.kiev.ua> сообщил/сообщила в новостях следующее:
news:2.07b5.RYAZ.FWF6VG@nn.kiev.ua...
> At 19-Jun-00 17:52, Nick A. Leuta wrote:
>>>PAM-то не расскажет ядру о UID, а вот упомянутый мной NSS в Linux'е(и
>>>Solaris'е, откуда у него ноги и растут) расскажет и покажет, и не только
об
>>>этом (цитирую мануал: "aliases, ethers, groups, hosts, networks,
protocol,
>>>users, RPCs, services).
[skiped]
> NL> Hу, по NSS (Nameservice Switch) начинать рыться могу посоветовать с
> NL> glibc 2.х/Linux
[skiped]
> Я-то думал, что имеется в виду netinfo или NIS+, а вон оно что. ;(
> Тогда завеpяю Вас, что что-то Вы не понимаете в идеологии - потому что
> nsswitch есть не сpедство, а всего лишь полуметаидея-полуидеология,
> несмотpя на то, что оно офоpмляется отдельным конфигом.
Hу, как самостоятельное средство оно и не требуется :-) Оно нужно для того,
чтобы унифицировать способ взятия откуда-нибудь исходных данных для
последующей отдачей их функциями вида getpw*() (getpwnam(), напр),
getserv*() (getservent(), напр.), getproto*(), ether*() и т.п.
Если на то пошло, то перечисленные функции и придумали специально для того,
чтобы приложение не парсило самостоятельно всякие там /etc/* типа passwd,
master.passwd/shadow, networks, protocols и т.п., чтобы при необходимости
можно было правкой библиотечных функций изменить источник информации,
хранящейся в этих файлах. А NSS доводит эту идею до логического конца,
исключая необходимость править сами библиотечные функции, а вместо этого
править конфиг: надо - используем NIS/NIS+, надо - локальные файлы, надо -
LDAP, а хоть и все сразу, а можно и без чего-нить из этого...
> И к паму оно как бы совеpшенно оpтогонально ;)
Каждый по отдельности - действительно самостоятельны, и действительно
неполноценны: PAM не может дать соответствия login<->UID, а NSS далеко не
всегда может вытащить пароль (далеко не всякая аутентификационная система
может его отдать, либо потому, что не может, либо даже может, вот только
кодирован он не так, так это ожидается от значения, возвращаемого
getpwent() ). Hо вот вместе (систему не равна сумме компонентов :-) ) они
полностью справляются с задачей аутентификации, и даже больше:
аутентификационная логика в приложении сводится к минимуму, а что происходит
в процессе аутентификации, зависит только от фантазии сисадмина и авторов
pam_* модулей: например, можно давать/отказывать в доступе в зависимости от
фазы луны (ибо она неплохо рассчитывается).
> >> а kerberos не более простое решение? (его даже win поддерживает)
> NL> Вроде как в свое время были разговоры и поддержке kerberos'a в Win2K.
> NL> Больше из не-UNIX'ов (NW, NT) никто его не умеет.
> NL> Если уж на то пошло, то самое простое решение для UNIX'ов - это NIS.
Hо,
> NL> в
> NL> отличии от kerberos'a и NIS'a, LDAP живет практически на всех
платформах.
> Как бы засовывать тех же юзеpов в LDAP - ну совеpшенно неудобно.
А рулить локальными юзерами на десятке машин удобнее?
> И надо патчить ту же libc (g- или нет - пофиг) на эту тему ну совсем
> не pадует...
Патчить фрюшные библиотеки (или портировать glibc (где nss и живет,
собственно) на FreeBSD)? Тут легким патчем не обойтись - задача достаточно
серьезная. К тому же просто прикручивать nss ради nss смысла мало, надо еще
и pam, а значить и изрядное количество стандартных утилит тоже править...
Плюс еще о портах не забыть...
===================
* Паранойя - профессиональное заболевание системных администраторов...
SkyNick
--- ifmail v.2.15dev5
* Origin: Lipetsk State Technical University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
