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

Everything you've described though is problems with an implementation, not
specificly with the protocol/API. Using a bad linux implementation as the
showcase for why someone shouldn't use a specific API would mean a lot of
different API's should be discarded due to bad/hacked up linux 
implementations...

James