Subject: Re: PAM stinks.
To: None <email@example.com>
From: sudog <firstname.lastname@example.org>
Date: 10/01/2001 10:18:35
On Sunday 30 September 2001 14:36, Miles Nordin wrote:
> begin email@example.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.
> 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.