Re: Is it too late to try and generalize PAM for woody?
Hi Daniel,
On 26 Jun 2001, Daniel Martin wrote:
> I've been following this thread and I have a small question as to why
> we'd need to overload/change the semantics of the /etc/pam.d/other
> file.
> Why not merely build a new pam module, called something like
> pam_chain, that does nothing but invoke other pam modules as specified
> in its configuration? To get an example of what I mean:
It's possible to do this, in fact RedHat now uses a module they wrote called
pam_stack to do just that in all of their config files (RH 6.2 and above, I
believe).
My concern is that, while this makes it easy to handle inheritance from the
POV of the app maintainer, it is programmatically quite complex to take the
complete state associated with one PAM handle, pass it to another handle, and
communicate any changes made on the child handle back to the parent. With no
slight intended to the RedHat programmers who work on PAM, I would be
astonished if pam_stack worked flawlessly with the pam_krb5 module I've been
working on, simply because it uses so many of PAM's features to the very
fullest.
OTOH, this means it would make a good module for stress-testing pam_stack or
an equivalent... I'm just concerned that if we use pam_stack in Debian, that
we'll still be chasing down obscure bugs three or four years from now as a
result.
> In /etc/pam.d/ssh:
> auth required pam_chain.so chain=default
> account required pam_chain.so chain=default
> session required pam_chain.so chain=default
> password required pam_chain.so chain=default
> Then, in /etc/security/pam_chain.d/default (Or a better file name -
> I'm open to suggestions), we'd have:
If Debian moves to a pam_stack-style solution, I'm strongly in favor of
leaving /etc/pam.d/other as it stands right now; in fact, even using
/etc/pam.d/other as the target config file for pam_stack sounds like a good
idea to me. That way, applications whose PAM config needs *no* modification
from the default can use PAM's built-in functionality directly, without either
the overhead or the potential complexity of pam_stack.
Steve Langasek
postmodern programmer
Reply to: