dan,

we seem to be talking past each other...

On Sat, 7 Dec 2002, Dan Melomedman wrote:

> 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.

so you are agreeing with me.  you just want to keep specifying.  that's 
fine.

> > 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.

so you lack a sense of humor.  (that snark about freebsd was a joke.)  
that's fine, too.

> > 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.

i guess it depends upon what you mean by flexibility.  you're right, the 
mailalternateaddress functionality of qmail-ldap is nice.  on the other 
hand, the fact that i get configurability of various kinds of 
authentication and authorization for *all* system services out of PAM is 
also nice.

so it depends on what you want.

> > 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.

so you don't have data on the performance of LDAP authentications against 
PAM.  too bad.  i was hoping to see some.  anyway, we'll throw out the 
"faster" claim that you made about qmail-ldap until we see those data.

i'll agree that PAM can be confusing and tough to troubleshoot.  still, on 
systems that come pre-configured with PAM, it's trivial to modify it and 
add additional sources of authentication.  

i set up local users out of a netscape-directory server on redhat linux 
several years ago, even before the ldap stuff was integrated, and found 
that it worked just peachy.  sorry you had troubles configuring it.

> > 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.

here's the point i think you're missing (that perhaps i haven't made 
clearly):

the additional amount of code needed to support PAM on a system that comes 
bundled with it is 0.  the additional amount of code needed to support 
LDAP in qmail in >0.

i can do a number theory proof that '>0' > '0' but it would take a while 
and might involve large numbers of 'S's.  :-) (that was a joke).

people who are already using systems that are pamified and primarily want 
qmail-ldap for user authentication/authorization should use PAM.  people 
who don't meet those two criteria shouldn't.

that's my claim and i'm sticking to it!

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

Reply via email to