I fail to see what is broken about this. Perhaps you could clarify your position again?
I think the question is, why should a module that returned PAM_AUTH_ERR in the auth phase be expected to return PAM_SUCCESS or PAM_IGNORE in the cred phase -- and is this really what existing modules are doing? It seems more intuitive to me that if a module didn't contribute to the return value of the stack in the auth phase, it should also not contribute to the return value of the cred stack; and I gather this is not what's happening.
I'm not rejecting this comment. It clarifies a point of view that I need to think some more about. However, I do want to make some observations:
1. in the case that there are no jumps, based on an old annecdote, I believe this behavior mirrors better what Solaris' PAM does - someone should verify this and report (Thanks!).
2. the whole setcred thing is a real mess. If you go back and look at the specs you will find that it is entirely unclear how the setcred function (in its four different modes) is supposed to be called, and what exactly a credential is - its not a uid for example. [This speaks to the 'what are modules actually doing' comment.]
3. the frozen chain/return code behavior is used by auth/cred, session(open/close), and the two chauthtok calls, so please think about the behavior you want in these cases too.
I'm not against changing something that is broken. This frozen chain stuff is a fairly new, and feedback may improve its design/implementation.
Please continue to comment.
Cheers
Andrew
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
