Automatic testing of pam modules

[R Hannes Beinert]

Hello Dan,

--- On Mon, 6/23/08, rozelak at volny.cz <rozelak at volny.cz> wrote:
> 
> did you just compiled your own pam library to use paths
> from env variables, or did you also do some hacks which
> sould be useful?

I primarily patched the latest version to obtain pathnames
from environment variables.  I also directed system logging
to a file.  My aim, however, was to modify the original PAM
code as little as possible, since I want to reduce the 
possibility of introducing anomalous behaviors due to the
changes themselves (is that Heisencode? :-).

> How do you build test(s)?

My current idea is that the testing really involves a "dialog"
between the test application, and the module.  The libpam
layer itself really only serves as the glue, although I do
build it with debugging enabled, and did add a few debugging
D() function calls so that internal libpam activity was a little
more visible.

The module itself has a "test" parameter which allows it to 
adapt its behavior slightly to the test environment.  This is
probably suboptimal, since my preference is to test production
codepaths rather than codepaths unique to a test environment.

This approach is workable, since it does allow testing a real
build of the PAM module, in a reasonable facsimile of the real
PAM environment.  It does avoid the need to test in the context
of the current system PAM configuration -- which was one of
my goals.

There are problems with this approach, though, in that one must
necessarily monkey around with the way the various DSOs are loaded,
and ensure that the production libraries aren't accidentally
accessed by the dynamic linker.  This, by its nature, implies that
the test setup is far from portable between platforms.  For a
generalized solution, there is also the potential issue of API/ABI
compatibility, too, I suppose.

Hannes.