Todd Underwood wrote: > > For me, PAM is secondary. Straight LDAP is better. Not all *nix supports > > pam-ldap. Furthermore, PAM is bloated, hard to debug, understand, and > > write modules for; with the additional requirement of dynamically linked > > binaries. Statically-linked binaries can load much faster (especially > > when they're small). Take a look at the PAM API. > > so you're agreeing with me: one good reason to use qmail-ldap is if > you're using an OS that doesn't support PAM. another is if you trust the > qmail-ldap modifications more than you trust the PAM-LDAP stuff.
It's not a matter of trust, there are many reasons why I dislike PAM, and they have been discussed on other mailing lists. The other reasons are stated below. > > Or FreeBSD, or any other OS which doesn't have pam-ldap or equivalent > > available. However, native LDAP support is more flexible, simpler, and > > faster. > > ok, you could be using freebsd (although why you would, i'm not sure. > *ducks*). i disagree that native LDAP support (by which i'm assuming you > mean native to qmail rather than native to the OS) is more flexible, > simpler or faster. We run FreeBSD primarily because it's easier to administer and upgrade than let's say RedHat distributions, but this is unrelated. > it seems to be obviously not more flexible. PAM is flexible to a fault. Obviously how? pam-ldap only pulls your essentials out of LDAP. What about mailalternateaddress, the quota, etc., which qmail-ldap supports out of the box without PAM. This is another very good reason for not using PAM. PAM only gives the basic functionality at a high cost. > that's why you found it hard to understand and debug, right? it's not > simpler when PAM-LDAP is bundled with your OS and all you have to do is > type 'authconfig' to put the right values in /etc/ldap.conf and > /etc/nsswitch.conf. faster? i don't know. have you benchmarked the two. > if so, please report numbers. if you're speculating, please stop. I found it hard to understand and debug by 1) Reading the pam-ldap docs. 2) Trying to run the damn system. > > > 2) you are using a PAM-capable OS but you trust the qmail-ldap patch's > > > implementation of LDAP authentication/authorization more than you trust > > > the PAM implementation. You're trying to reduce your exposure. this is a > > > judgement call for you to make. i personally would rather use PAM-LDAP > > > than add *huge* amounts of code from various sources to an otherwise > > > extremely secure product (qmail), but YMMV. > > > > Compare the size of the pam-ldap source to the size of qmail > > source. > > so you have decided that you trust large modifications to the qmail source > over large amounts of code in the authentication path. that's one > rational decision (as i very clearly indicated in my original post). > another rational decision would be to benefit from the inherent security They're not so large. The amount of code needed to support PAM is huge by comparison to qmail source code alone even without the patch! Furthermore, the qmail-ldap modifications are applied to several qmail processes, but not all. It's up to the administrator which modules to run modified or not. Also what I think qmail-ldap developers should have the patch split into several patches for easy to pick-and-choose. but that's probably much more work.
