On Fri, May 16, 2003 at 02:04:06PM -0700, Andrew Morgan wrote: > I guess I'm completely confused by your observations. Could you try > again to explain what you think is wrong? > Here is how it works: > The jumps are taken/not taken in exactly the way they were 'frozen' in > the 'auth' phase - the return codes from the 'cred' phase don't affect > the path through the stack - just the final return code. > In the auth case, the module should be able to determine if it likes the > user: the admin defines the path through the stack based on the modules > return codes, and this path is frozen in the 'auth' phase. If the module > likes the user when run in its 'auth' mode, it may have a credential to > offer in the later phase - or it can say 'I know you authenticated > before, but I've just encountered a credential setting error so we have > a problem and I'm throwing you an error in this setcred phase'. > In the case that the module fails the auth, when it is invoked in the > setcred phase it should return PAM_SUCCESS (=I did nothing and that's > ok) or PAM_IGNORE (=I did nothing). > Again, the jump directions are not dictated by the 'cred' responses in > any way. They've been frozen in the 'auth' phase. The only thing that > the 'cred' responses affect is the final return code from the > pam_setcred() call. > 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. -- Steve Langasek postmodern programmer
Attachment:
pgp00085.pgp
Description: PGP signature
