|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Nick A. Leuta 2:5020/400 13 Oct 2001 18:46:19
To : Alex Semenyaka
Subject : Re: ящики развести
--------------------------------------------------------------------------------
"Alex Semenyaka" <Alex.Semenyaka@f640.n461.z2.fidonet.org> сообщил/сообщила
в новостях следующее:
> NL> "Alex Semenyaka" <Alex.Semenyaka@f640.n461.z2.fidonet.org>
> NL> сообщил/сообщила в новостях следующее:
> "сообщило" :)
Ломы ньюсридер переучивать - да и новый скоро ставить буду...
> NL> Во-первых, пароль (т.е. аутентификация) не так уж часто нужен - тому
> NL> же ls, find, chown, например. К тому же аутентифицироваться нужно
один
> NL> раз, а ls'ить можно хоть до ребута.
> Конечно. Hо когда множество {a} проверяется одним способом, а множество
> {(a;b;c)} - совсем другим - мудро ли сие? И мудро ли, что в последнем
случае c
> задан набор неких конкретных фиксированных смыслов? IMHO - нет.
Множество {a} - _не_проверяется_. Иными словами - NSS избыточен из
соображений обратной совместимости - у меня, например, аутентификация
производится в LDAP, и в качестве пароля NSS отдает стандартную заглушку для
случаев, когда ему туда ничего не пишут, а поле должно быть для getpwnam()
чем-то заполнено. Аутентификация идет через PAM, и в итоге они не
пересекаются.
> NL> А ядру оно и пофиг как раз :-) Можно переделать login так, чтобы он
> NL> воспринимал UID (a-la UIN в ICQ), и тогда половина NSS, ответственная
> NL> за passwd, становится не нужна нафиг. Про существование
> Мнэ, мы всё еще про реальный мир и реальные задачи?
Да пока еще да: дайлапных или аськовских юзеров через PAM можно (в принципе)
аутентифицировать без проблем. Проблемы начинаются из-за чисто человеческого
фактора - ну удобнее username в использовании, чем числовой UID. Вот
появляется подсистема в виде /etc/passwd (причем в Linux'е в отличии от
FreeBSD - разное происхождение shadow - passwd это не переделанный shadow
(т.е. master.passwd во Фре) - это сильно разные файлы, пересекающиеся (но не
обязательно совпадающие по количеству) только по полю username), которую NSS
попросту отвязывает от файла, позволяя держать соответствия username:UID
хоть в NIS, хоть в LDAP, хоть в SQL.
> NL> Система не так уж и ущербна, но нельзя объять необъятное - если один
> NL> механизм аутентификации для своей работы требует пароль в
> NL> незашифрованном виде, другой - хеш, третий - тоже хеш, но другой, и
из
> NL> первого не получаемый... Hу как их все привести к одной общей базе?
> Подумать головой заранее, перед разработкой, а не после - а как ещё? :)
Проблема тут в том, что PAM часто выступает как прокси между (порой,
_сильно_ разными) механизмами аутентификации - ну, например, между
SMB-аутентификацией и локальным passwd. Он сумеет (по крайней мере в
принципе) по-отдельности и то, и другое, но вот из одного в другое
переделать - задачка нетривиальная. В самой самбе из-за этого smbpasswd
ввели.
> >> механизмы, применение которых постоянно натыкается на ограничения :(
> NL> Какие, например?
> Hапример, какой набор PAM_* бывает? :)
А :-) Hу мне однажды приспичило добиться того, чтобы юзернеймы вводились
только в нижнем регистре (для чего... для сквида зачем-то...). Hу, минут
через 15 еще одним модулем прибыло :-)))
===================
* Деньги - зло! Для получения подробной информации пришлите 10$
SkyNick
--- ifmail v.2.15dev5
* Origin: Lipetsk State Technical University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
