The error status for the setcred sequence is treated as if the module was listed 'cred required ...'. That is, the chain will execute everything and fail if one of the modules returns an error.
If your setcred invoked module is returning an error because its auth execution returned an error, you need to modify your module to make its setcred function return PAM_IGNORE or PAM_SUCCESS in this case (I would suggest the former).
Cheers
Andrew
Sam Hartman wrote:
Hi. I'm the Debian PAM maintainer and it came to my attention in Debian Bug #176693 (http://bugs.debian.org/176693) that there seems to be a bug in howskip actions are handled in _pam_dispatch_aux when a cached chain is in use.
In particular consider the following pam configuration:
auth [success=ok default=1] pam_krb5.so forwardable
auth option pam_openafs_session.so
auth Note that you probably don't want that configuration for other
reasons, but that's unrelated to the PAM bug.
If pam_krb5.so returns an error it is correctly skipped in the auth phase. However when the cached chain is used, an error is treated as fatal by the skip action.
As it turns out a user unknown error is going to make both the auth and the setcred behavior fail.
Why would you want to ignore the error in the auth phase but care about the error in the setcred phase? Can you give me an example of a set of modules and pam configuration for which this is the right behavior?
If not, I'll change the behavior in Debian and submit a patch.
_______________________________________________ Pam-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/pam-list
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
