On Wed, Oct 8, 2008 at 4:22 PM, Nicolas Williams <Nicolas.Williams at sun.com> wrote: > In order to test pam_eval() I've written a pam_test.so.1 module that > takes arguments like: > > - debug > - trace > - getuser > call pam_get_user() > > - return=<return-value-name> > set module return value > > - return_if=<return-value-name> > return immediately if the current module return value matches > > - depth_limit=<depth-limit> > set depth limit (for testing pam_eval()); when reached return current > return value > > - limit=<depth-limit> > set limit on invocations (for testing with pam_eval() *and* include); > when reached return current return value > > - eval=<config-name> > call pam_eval(<config-name>) > > - conv_err=<string> > - conv_info=<string> > - echo_on=<string> > - echo_off=<string> > Add a conversation or prompt > > - conv > call conversation function now and reset the previous messages > > Should we just integrate such a module? It could be very useful for > PAM application developers as well as for ON developers.
In a related vein, a while ago, I wrote a simple application that'd allow one to exercise the pam stack of an arbitrary service (it did authentication, authentication, open session, close session, as well as the data prompting iirc). It'd be fairly trivial to write again (I have long since lost the original source). I found it useful for testing -- i could create a 'dummy' service w/ the config i wanted, test it using the program to make sure things worked right, before implementing the changes to a specific service (or other) with minimal risk of bricking the box. If people feel it might be useful to have, I'm open to writing it again.
