dan, all, On Sat, 7 Dec 2002, Dan Melomedman wrote:
> Todd Underwood wrote: > > i don't agree. qmail+qmail-ldap is one way to do it, but in my opinion it > > duplicates a bunch of common code that already exists on PAM-capable OSes > > (like linux & solaris). if you use a PAM-capable OS and just configure > > the OS to authenticate and authorize users out of LDAP, qmail sees them as > > standard users (all of the standard C library functions for things like > > getuid gateway to PAM which gateways to LDAP). > > 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. > > 1) you are using OpenBSD for its security properties. in spite of the > > ongoing debacle that was OpenSSh last winter and much of this year, > > OpenBSD is still more secure than most OSes out there. it doesn't support > > PAM (probably because PAM is hard to code securely and hard to code at > > all). > > 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. it seems to be obviously not more flexible. PAM is flexible to a fault. 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. > > 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 in qmail by *not* modifying the source with a massive patch from a bunch of different sources and instead rely on the authentication chain being sound (or at least more hidden from attackers than a service listening on an unfiltered network port). both strategies seem valid (but debatable) to me. my point was to suggest that for some people the second is a better strategy. t. _ todd underwood, vp & cto oso grande technologies, inc. [EMAIL PROTECTED] "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." - Benjamin Franklin
