[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: porting PAM
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: Re: porting PAM
- From: Chuck Yerkes <chuck+obsd_(_at_)_2003_(_dot_)_snew_(_dot_)_com>
- Date: Wed, 28 May 2003 13:35:49 -0400
- Mail-followup-to: Chuck Yerkes <chuck+obsd_(_at_)_2003_(_dot_)_snew_(_dot_)_com>, tech_(_at_)_openbsd_(_dot_)_org
Quoting Bob Beck (beck_(_at_)_bofh_(_dot_)_cns_(_dot_)_ualberta_(_dot_)_ca):
> >Now of course Theo was talking about something other than PAM. But
> >it's true, BSD Auth is a reinvention of the wheel that causes people
> >interoperability problems. The lack of PAM and nsswitch continues to
> >keep OpenBSD in an infrastructure appliance role or standalone server
> >on most networks.
> Wow, my eyes are open for the first time. the lack of PAM and
> nsswitch relegates an os to an infrastructire appliance role or
> standalone server on most networks..
Lack of nsswitch, or really a generic wrapper for the get...(3)
routines (getpwent(), getprotoby...(), etc), means that we have NIS
for name services rather than being able to extend them (LDAP scales
a bit better than NIS).
While BSDAuth addresses the password/auth part of the game, a
machine with no /etc/passwd entries for a user is less than
I really don't want dynamically loaded (or changable on the fly)
libraries for name services, but being able to say something like:
group: files, ldap (query="gid=%0,dc=NIS,dc=example,dc=com" group)
would be really nice.
PAM varies, yes. I attended the Usenix talk that Ted T'so did
about seeing PAM at Sun and implementing it for Linux a year
before Sun had anything out. I'd suggest that it's an existing
wheel that could be fixed. Done well, perhaps the other BSDs
do what they did with Theo's NIS stuff: adopt it wholesale.
Visit your host, monkey.org