1. query all modules in the stack and get some confidence that the update will work
2. run all the modules in the stack a second time to actually do the update.
The purpose of returning PAM_TRY_AGAIN is so a module can inform the app that now is not a good time for the update (during phase 1) and avoid phase 2 from starting.
If this is what you are actually trying to do, then you should use PAM_TRY_AGAIN in the first invocation.
The documentation for pam_get_item() should be more explicit: it either returns PAM_SUCCESS or PAM_BAD_ITEM.
Lastly,
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-3.html#ss3.1
With supplemental stuff available only to modules here:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_modules-2.html#ss2.1
Cheers
Andrew
Michael Chang wrote:
Hi folks.
I'm currently writing a module, and while the documentation is *okay*, there are some points which I'd like clarified:
pam_sm_chauthtok(...) If, during the preliminary check, the old authentication token was unable to be retrieved, is it okay to return `PAM_AUTHTOK_RECOVERY_ERR'? The documentation implies that the only valid return value during the preliminary check, in case of failure, is `PAM_TRY_AGAIN'.
pam_get_item(...)
For modules which call this function, the documentation does not state what the possible return values are.
Lastly: Is there any _full_ and well-prepared list of return codes and item types (used by pam_get_item() and pam_set_item() for `int item_type') anywhere?
Thanks in advance, Michael
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
