From 3ff5b4d64753c2cd730acc803f1b6793a1f4bf07 Mon Sep 17 00:00:00 2001 From: Steve Langasek Date: Tue, 4 Jul 2000 04:39:35 +0000 Subject: 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. --- modules/pam_unix/pam_unix_passwd.c | 19 +++++++++++++++++-- 1 file 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; /* */ @@ -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); -- cgit v1.2.3