Pam conversations per se may also run in parallel, but this implies that
the application supports this.
Since this normally not the case, do not create modules that may invoke
the pam conversations in parallel by default, adding a mutex to protect
such calls.
In order to properly test the interaction of a module transaction from
the application point of view, we need to perform operation in the
module and ensure that the expected values are returned and handled
In order to do this, without using the PAM apis that we want to test,
use a simple trick:
- Create an application that works as server using an unix socket
- Create a module that connects to it
- Pass the socket to the module via the module service file arguments
- Add some basic protocol that allows the application to send a request
and to the module to reply to that.
- Use reflection and serialization to automatically call module methods
and return the values to the application where we do the check
This function is only needed when using go PAM for creating applications
so it's not something we expect to have exported to library modules.
To prevent this use an `asPamModule` tag to prevent compilation of
application-only features.
A PAM module can be generated using pam-moduler and implemented fully in
go without having to manually deal with the C setup.
Module can be compiled using go generate, so go:generate directives can be
used to make this process automatic, with a single go generate call as shown
in the example.
Lars Scheibling
Marco Trevisan (Treviño)