Rainer Weikusat <rainerweikusat@???> wrote:

>> That's what I've always assumed - and IMO it seems like a sensible
>> idea. After all, people don't generally object to the idea of programs
>> calling various libraries instead of "doing their own thing".
>
> Well, I certainly do object to this idea: Each program still "does its
> own thing", just using a different API, and there's nothing magic about
> "libraries" which would automatically cause "library APIs" to be better
> designed and better implemented than "application code" and especially,
> than "other library code", eg, using the Kerberos libraries for Kerberos
> authentication is certainly less roundabout and less loaded with
> seemingly arbitrary byzantinsim than using GSS API or - heaven forbid -
> the PAM API.
>
> NB: This it not supposed to be a general statement against "use of
> libraries", just a call for making in intelligent descision about that
> depending on a specific situation instead of a "X is always right!" "But
> Y is always much righter!" knee-jerk approach.
>
>> That's perhaps the main issue - with flexibility comes complexity. But
>> in this case, I'd have thought that the flexibility of allowing "any"*
>> program to use "any"* authentication method by supporting just one
>> module should be considered a "good thing".
>
> If that one module is so hideously complicated that it will likely end
> up being broken in many subtle and not-so-subtle ways, and that's
> certainly the case for the PAM API, you'll end up with a program which
> supports no authentication method or certainly none it wasn't tested
> with.

I think my post wasn't too clear. I'm not arguing in favour of PAM itself - but the idea behind it. PAM may the best thing since sliced bread, or the stinkiest pile of poo - I don't have the technical skills to say (you seem to think the latter). But IMO the principle of something that allows any program to simply use any authentication method with one API call to a pluggable system does seem to make sense.

The alternative is different programmers deciding to support different subsets of methods, and even if they use standard libraries (rather than re-inventing it themselves with a fresh set of limitations and bugs) I imagine they'd tend to have different APIs. So yes, you are correct in one way that calling a Kerberos library would be a more direct route - but that means the programmer must program that in, and program in method X and method Y and method Z using their respective libraries.
But IMO it does seem to make sense to have a subsystem that acts as an intermediary so that the programmer of any specific application doesn't have to consider which methods he wants to support. He just needs to program one "authentication" API and the user/admin can decide what modules he needs for his purposes.