This issue is a good one to start a thread of its own. There are three types of module stack that are problematic from the perspective of PAM: 1. the credential setting stack 2. the pam_sm_chauthtok stack 3. the session stack (open vs. close) These module stacks can be called multiple (2 or more) times, and sanity requires that the same (equivalent) sequence gets invoked on each occasion. The credential sequence is logically dependent on how the pam_sm_authenticate() got called. Our hack to make this go smoothly (from an admin's perspective), is to add 'likeauth' arguments to modules to encourage them to return the same value when called in both setcred and authenticate ways. This is ugly, not well implemented and thus problematic. The chauthtok stack needs to execute the same way both times it is called (PRELIM_CHECK and UPDATE_AUTHTOK). Currently, its strongly assumed that each module does the right thing - we have stated/documented no policy for this. The session stack is problematic for two reasons: a. we can't nest session modules since they close in a different order to the way they open b. we rely on the session modules to return the same error codes to drive the session stack the same way at both session open and close times. Going forward, I believe we should solve this in libpam. We should cache the path that these modules take the first time they are exectuted with a successful result and that will dictate the way they get recalled until pam_end() is invoked. [This is very vague, and needs a full discussion before we commit to changing anything...] Cheers Andrew Michael Tokarev wrote: > That's ok, but issue is not here. Issue is in stacking with other > modules, and with some other (less-common) things. > chauthtok() called twice, and this is not a question. But the real > question is -- will it be called with UPDATE_AUTHTOK if it returned > error when called with PRELIM_CHECK set earlier? This can happen > if that module was declared "sufficient" while other module (that > did authenticated user) as "required"/"sufficient". In the other > hand, other modules can change authtok on its own (due to even > admin mistake), so things will be more "interesting". > Also (less-common) thing is a locking. It is bad idea to lock > passwd database(s) during all passwd stack work (I said this > earlier already). And so, after verifying current passwd, there > is a chance to have it already updated (by someone else?! :) > when we will try to update it at the end. So, this checking > of old passwd compared to system's one _when updating it_ is > useful here too. > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list
