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.
Modules have the ability to start PAM conversations, so while the
transaction code can handle them we did not have a way to init them.
Yet.
So add some APIs allowing this, making it easier from the go side to
handle the conversations.
In this commit we only support text-based conversations, but code is
designed with the idea of supporting binary cases too.
Added the integration tests using the module that is now able to both
start conversation and handle them using Go only.
Module data is data associated with a module handle that is available
for the whole module loading time so it can be used also during
different operations.
We use cgo handles to preserve the life of the go objects so any value
can be associated with a pam transaction.
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.
This allows to easily define go-handlers for module operations.
We need to expose few more types externally so that it's possible to
create the module transaction handler and return specific transaction
errors
Marco Trevisan (Treviño)