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.

1 files changed, 17 insertions, 2 deletions

diff --git a/modules/pam_unix/pam_unix_passwd.c b/modules/pam_unix/pam_unix_passwd.c
index cfa294f8..a3925895 100644
--- 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);