| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Style types
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.
|
|
Check if a transaction is ended in in tests.
|
|
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
|
|
As per previous commit, Transaction can't be used anymore as an error
value, but we instead we always return the status code.
|
|
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.
|
|
And use them instead of C ones. Given that we have strings for them we
can easily implement error interfaces for it too.
|
|
|
|
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().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
