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
A pam handler can be used both by a module and by an Application, go-pam
is meant to be used in the application side right now, but it can be
easily changed to also create modules.
This is the prerequisite work to support this.
We redefined various PAM constant values for items, flags and style, but
only few of them were marked as being Item's or Flag's. This caused go to
just consider them as generic integers instead of the actual subtype.
A PAM transaction needs to be ended in order to release the associated
resources, however this can't be sadly automated as the go finalizers
run in goroutines and this could cause problems to modules that we load.
In fact a module code may be called back during pam_end (to cleanup data
for example) and the module code could not be thread safe.
So let's make this more manual, but safer.
The transaction status is still preserved in the transaction so end will
be automatically called with the last-known status.
Closes: #14
While transaction does implement error, it's not a valid error
implementer because it may have bogous values since it's not thread-safe
and so we may read the result of Error() when it's into an invalid state
As per this never return it as an error, while always return the Status
unless when not available, where we still return pam.Error.
Transactions save the status of each operation in a status field, however
such field could be written concurrently by various operations, so we
need to be sure that:
- We always return the status for the current operation
- We store the status in a atomic way so that other actions won't
create write races
In general, in a multi-thread operation one should not rely on
Transaction.Error() to get info about the last operation.
All the pam functions return an integer with the status of the operation
so instead of duplicating the same code everywhere, that is quite error
prone, use an helper function.
It would have been nice to make this more dynamic, but cgo doesn't allow
us to do much magic here.
This is enough though.
If the transaction fails during start, there's no way to get the error
detail in a programmatic way, so let's wrap the pam.Error to allow more
per-type checks.
PAM upports binary conversations using private protocols, this
can be handled by C but it's not supported here because we
implicitly convert all the messages to string, and this may lead
to issues when this is not the case (as in binary protocol the
pointer could contain zeros that the GoString conversion would
consider them the end of the message).
So, add another conversation handler implementation that allows
to handle the binary protocol, whose function callback accepts
a pointer to the struct (we can't use bytes as the length is
unknown and may be defined in the header of the pointer itself).
However since the binary prompt is not supported by all the
platforms we need to do a compile-time check to disable it in
case is used when not supported.
Go provides a nicer way to handle Go structs lifetime when they
are passed to C now, so use this instead of a custom
implementation that requires to store them in a map
PAM has a pam_start_confdir() which allows to define the configuration
directory where all services are located.
This is useful to define your own service on tests in particular, so
that you can control your stack and be independant of the host when
running them.
Allow defining this configuration directory, with a new StartConfDir
function.
Also, allow pre-checking for the API availability with
CheckPamHasStartConfdir().
