Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2) Gecko/20040308 Description of problem: When using the latest version of pam from rawhide, the passwd utility is broken because of SELinux patches and will not let you set a new passwd. I enabled pam debug to get this: [pam_item.c:pam_get_item(170)] returning user=root [pam_unix_passwd.c:pam_sm_chauthtok(1295)] password processed [pam_unix_passwd.c:_do_setpass(740)] called [pam_unix_passwd.c:_unix_run_shadow_binary(231)] called. [pam_unix_passwd.c:pam_sm_chauthtok(1309)] retval was 1 [pam_dispatch.c:_pam_dispatch_aux(84)] module returned: dlopen() failure It indicates that a dlopen failure occurred. HOWEVER If you dig deeper, you will see that it uses a little utility called unix_chkpwd. In pam_unix_passwd.c around line 297, you will see this: rc=waitpid(child, &retval, 0); /* wait for helper to complete */ if (rc<0) { _log_err(LOG_ERR, pamh, "unix_chkpwd waitpid returned %d: %s", rc, strerror(errno)); retval = PAM_AUTH_ERR; } else { retval = WEXITSTATUS(retval); } It basically sets retval to whatever the exit code was from unix_chkpwd. This doesn't sound like a dlopen() problem. Looking inside unix_chkpwd.c around line 306 is this: retval = _unix_verify_password(forwho, pass, 0); if (retval != PAM_SUCCESS) { return retval; This unconditionally returns the return code of _unix_verify_password if its not PAM_SUCCESS. Looking at that function, I see int retval = UNIX_FAILED; Looking up UNIX_FAILED, I see its set to a 1. This would not be the correct pam return code. This is what's causing the dlopen failure message, but the bigger question is "why is it verifying a password that is being changed?" It obviously will fail since it doesn't agree with what's in the shadow database. Please fix? Running the passwd utility appearantly has not been tested. Version-Release number of selected component (if applicable): pam-0.77-47 How reproducible: Always Steps to Reproduce: 1. passwd 2. Enter the new password 3. Enter it again 4. Boom Actual Results: passwd: dlopen() failure Expected Results: All tokens successfully changed Additional info:
Modified unix_chkpwd to exit with all pam Error codes pam-0.77-50
Thanks Dan. Its much less of a wild goose chase now. ;) I recompiled -50 & installed it and now I get this: [root@buildhost root]# passwd Changing password for user root. New UNIX password: BAD PASSWORD: it is too short Retype new UNIX password: passwd: Authentication failure Can you test exactly as above? Run passwd as root, set the password to 12345. (I know its a stupid password, but it *is* the test.) Does root's password successfully change? There might also need to be some D() macros added to the pam-selinux patch in the unix_chkpwd utility for debugging problems like this. As it is, there's no way to see why/where unix_chkpwd is failing. D() macros are only compiled when the debug option is set in ./configure, so it should not be a security concern. Just a suggestion...
Works for me. passwd Changing password for user root. New UNIX password: BAD PASSWORD: it is too short Retype new UNIX password: passwd: all authentication tokens updated successfully.
Of course I am using targeted policy.
Thanks Dan. I relabeled the filesystem and everything works now. The cleanup of the error messages in unix_chkpwd looks good. This bug report can be closed.
I have 2 servers 1 works fine and the other I get. [root@ns1 root]# passwd Changing password for user root. New password: BAD PASSWORD: it is too short Retype new password: passwd: dlopen() failure