Re: Is it too late to try and generalize PAM for woody?

[Daniel Martin <dtmartin24@home.com>]

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:

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:

auth       required     pam_nologin.so
auth       required     pam_unix.so
auth       required     pam_env.so

account    required     pam_unix.so
account    required     pam_access.so

session    required     pam_unix.so
session    optional     pam_lastlog.so
session    optional     pam_motd.so
session    optional     pam_mail.so standard
session    required     pam_limits.so

password   required     pam_unix.so

In other words, pam_chain would be a pam module that would read an
alternate configuration, and parse it just as libpam does.  This
should be functionally equivalent to having a C-style #include
facility in pam files, yet it has the distinct advantage of not
requiring changes to the overall way that pam works, and of
maintaining some measure of compatibility upstream.

We could even write pam_chain to do fallback chains, so that you could
have /etc/pam.d/ssh say:

auth required pam_chain.so chain=ssh,encryptednet,interactive,default

and that would mean that pam_chain.so would first try to find an "ssh"
chain, then a chain called "encryptednet" (presumably for ssh and any
other encrypted channel), then an "interactive" chain, and finally
fall back to the default chain.  This could allow the sysadmin to
specify their pam options in a nice hierarchy, assuming we can trust
Debian developers to build up such a hierarchy.

(Add other syntax for pam_chain here - concatenating chains, allowing
one chain to say "act as though I'm not here", etc.)

Of course, this whole solution depends on my understanding of the main
problem with the current pam setup - have I missed some of what we
want to do that would not make this solution workable?