Relevant BUGIDs: 108845

Purpose of commit: bugfix

Commit summary:
---------------
Fix to pam_unix password changing code: if the password file is locked,
retry repeatedly to reduce the risk of leaving other authentication
databases in an inconsistent state when we fail.

diff --git a/modules/pam_unix/pam_unix_passwd.c b/modules/pam_unix/pam_unix_passwd.c
index cfa294f8201ba436e6c4b44d60c933a4151f63e8..a39258950d203120bee7288089e9312c145c6b7b 100644 (file)
--- a/modules/pam_unix/pam_unix_passwd.c
+++ b/modules/pam_unix/pam_unix_passwd.c
@@ -644,7 +644,7 @@ PAM_EXTERN int pam_sm_chauthtok(pam_handle_t * pamh, int flags,
                                int argc, const char **argv)
 {
        unsigned int ctrl, lctrl;
-       int retval;
+       int retval, i;
        int remember = -1;
 
        /* <DO NOT free() THESE> */
@@ -658,7 +658,22 @@ PAM_EXTERN int pam_sm_chauthtok(pam_handle_t * pamh, int flags,
        /* our current locking system requires that we lock the
           entire password database.  This avoids both livelock
           and deadlock. */
-       lckpwdf();
+       /* These values for the number of attempts and the sleep time
+          are, of course, completely arbitrary.
+          My reading of the PAM docs is that, once pam_chauthtok() has been
+          called with PAM_UPDATE_AUTHTOK, we are obliged to take any
+          reasonable steps to make sure the token is updated; so retrying
+          for 1/10 sec. isn't overdoing it.
+          The other possibility is to call lckpwdf() on the first
+          pam_chauthtok() pass, and hold the lock until released in the
+          second pass--but is this guaranteed to work? -SRL */
+       i=0;
+       while((retval = lckpwdf()) != 0 && i < 100) {
+               usleep(1000);
+       }
+       if(retval != 0) {
+               return PAM_AUTHTOK_LOCK_BUSY;
+       }
 #endif
        ctrl = _set_ctrl(flags, &remember, argc, argv);