On Sunday 30 September 2001 14:36, Miles Nordin wrote:
> begin  kpneal@pobox.com quotation.
>
> > *** Wouldn't PAM be easier and promote more code sharing?

No, it wouldn't. PAM is one of the most disgustingly implemented ideas 
I've ever had the displeasure to work with. I'll describe why, below;

> In short, my opinion is, it's the description of PAM which is so
> enticing.  Every actual implementation of PAM fails to deliver what it
> claims, is clumsily insecure, is buggy, or all three.

I don't think it's enticing at all. I think the idea is flawed, the 
implementation is flawed, and it doesn't make authentication 
easier--especialy messing with the authentication mechanism itself is 
particularly difficult in the PAM implementations I've ever seen.

> For example, I've seen PAM bugs on Linux systems that reveal whether
> or not a user exists at the login prompt.

Here's a better one; The last position I was at had Linux at its core, and 
the PAM module was sitting there as the authenticator for logins (via ftp 
etc.) We had about 50,000 users, and with that size of user database (in 
/etc/passwd) authentications via PAM were slow.

No, I mean it. So slow, the logins timed out before they could 
authenticate. So PAM would finally return a "yes, let him in", and the ftp 
daemon would say, "okay. woop, took too long. boot him."

There were no options for me to fix or improve this behaviour--until I 
built into the ftp daemon (and the others that were having trouble) the 
ability to read through the passwd and shadow entries themselves. Then it 
was lightning fast again to login.

Not fun. So that's the implementation that came with RedHat 6.2. 
Apparently it was a known bug. I hope they fixed it.

> The PAMs that I've seen are very bad at catching and reporting errors
> sanely.  That said, reporting authentication errors to someone
> requesting authentication is probably a bad idea, so this needs
> further elaboration---I only remember, ``poor error handling'' from
> when I used PAM.

To say the least. And with all the recursive inter-routine calls inside 
the PAM modules themselves, modification of basic items of authentication 
became a nightmare. If I wanted a special logging mechanism in the 
authenticator of a particular daemon to spit out a message to a logfile I 
could later grep through, modifying that evil PAM took enough time I had 
to give up on it or lose an entire day to just pissing around in the PAM 
source that came in the RedHat SRPM. It's messy. Really messy.

> Because PAM is incapable of interacting with the user (otherwise, the
> same module could not serve for xdm and login), less conventional
> authentication frameworks like S/Key, SecurID, crypto-iButtons, and
> so on render its entire architecture obsolete.

Thank god.

> Something like ssh authentication or POP3-over-SSL is hard to
> sledgehammer into the PAM framework.  You end up with even more
> special cases in programs like netatalk and Samba that require weird
> proprietary non-Unix authentication schemes to work optimally.  Do I
> want to:
>   a) send passwords in-the-clear over the network?, or
>   b) open up my Unix box to all the authentication bugs and back-doors
>      in NTAS?
> uu-uh.  uuh.  uhhhuhuh.  Doesn't PAM just make everything secure by
> centralizing it?

Ha ha..  yea. So one bug in PAM means my whole system of software gets 
compromised. And the code is so messy I wouldn't very easily fix the bug 
myself. wu-ftpd? Patch it myself. telnetd? Patch it myself. PAM? my god, 
the Lovecraftian portrayals that Sam Neill does on occasion would clap 
their hands in glee to see me deal with that piece of junk.

But, who knows? Maybe it's changed since then. Maybe the routines aren't 
so convoluted.. maybe the modern PAM is a friendly place with butterflies 
and dandelion seeds floating on lazy fall breezes...

Anyway..  that's my opinion. A fundamental flaw is easier to fix in a 
centralized system, but I'd still prefer the old-fashioned way until PAM 
gets its act together.

Marc