Jim Wise wrote:
> >
> >pam-ldap isn't the only way to do it. Just because your system support
> >pam-ldap, doesn't mean there aren't any other frameworks which are not PAM
> >which will do the same. We're using qmail-ldap, sqwebmail, courier-imap,
> >Cisco ACS, PHP scripts all authenticating from an LDAP directory,
> >without PAM. These packages are already LDAP-aware, so it's easy.
> 
> In other words, you're recommending that people who wish to use LDAP
> write/use five different LDAP client implementations, and then they
> still won't be able to do what Ross mentions, as none of ssh, rsh,
> telnet, etc. support LDAP at all?
> 
> I guess most people on the list can see why this is a non-starter.

No. We use the native LDAP support in those packages since it's already
done for us, and works just fine. You're turning what I say upside down.
Also - please don't reply to my address, I am subscribed to this list.

> >This isn't what's being discussed here if you didn't notice. What's
> >being discussed are merits and failures of different frameworks,
> >including PAM which will some day be included in NetBSD. The PAM
> >implementation which NetBSD may have in the future will not necessarily
> >mean you'll be able to use pam-ldap natively. Which, as I understand is
> >being written to support Linux as the first target. I believe it will
> >work with FreeBSD because FreeBSD borrows the Linux PAM.
> 
> So, in other words, you hold the fact that we might be dumb enough to
> implement something which calls itself PAM but is not compliant with
> everyone else's PAM implementations as a good reason for us not to
> implement PAM?

No. My point was PAM in NetBSD will not necessarily be compatible with
any of the available implementation, such as these implementations now
are not compatible either. I also wanted to stress what they
accomplished with pam-ldap could have been done with some other
framework. PAM isn't the only way to do it.

> >If however an authentication framework allowed for such simplicity that
> >writing an authentication module would be trivial - you could have
> >written one in a day or so, and wouldn't even be required to be written
> >in C. Which is exactly what an exec chain would allow for. Take a look
> >at pam-ldap source. It's a monster compared to the size of checkpassword
> >interface tools.

> I seriously doubt that an LDAP module for your imaginary
> generalized-exec-chaining-module-api would be any shorter than pam_ldap,
> and I'm quite sure that it wouldn't work in many of the contexts in
> which PAM is used (such as in apache modules or for database access).

Exec chaining can be so simple you can't exactly even call it an API.
Reading from a pipe up to 512 bytes of data which were written by parent
containing a username/password pair is hardly an API. Compare that to the
complexity of Linux PAM API, or the NSS API. Of course it's shorter. See
Felix Von Leitner's LDAP checkpassword - 
http://fefe.de/tinyldap/checkapssword.c.gz. A fair share of that code
deals with other stuff by the way since this one is specialized for
POP3/IMAP authentication; but who says you can't write a small generic
such module?