:: Re: [DNG] PAM usage
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng\@lists.dyne.org
Subject: Re: [DNG] PAM usage
Simon Hobson <linux@???> writes:
> karl@??? wrote:
>> I guess pam was an attempt to centralize auth things, before pam it was
>> ever daemon to its own.
>
> 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.

>> Useing pam doesn't hinder some daemon to ignore
>> it, depending how it is written. So you have to check booth pam and
>> daemon settings, it seems.
>
> 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.

[...]

>> And I fail to see what the big deal about PAM is in this case.
>
> +1
> Though I think the argument is that if you want to mount your root
> filesystem via ${random method} and ${random method} uses PAM for
> auth, then you need PAM support in advance of being able to mount your
> root. Hence the need for some form of temporary filesystem containing
> the support tools needed to get root mounted.


Random joke I can't resist quoting here:

Patient: Doctor! Doctor! Whenever I do X, it hurts terribly!
Doctor: Don't do X.