Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently trying to use pam_cracklib which properly fails according to my debug.log but even though it is setup as a password requisite entry in my PAM config file, it still falls through to the next pam_unix module which allows for a password change. Why is it allowing for a password change?

I am executing a login driver application through sudo, which is the only way I know how to authenticate.

Here is my PAM config file (named /etc/pam.d/validate):

auth  required
auth  required onerr=fail deny=3
auth  sufficient nullok try_first_pass 
auth  requisite uid >= 500 quiet
auth  required

account  required
account  required
account  sufficient uid < 500 quiet
account  required

password requisite debug retry=3 minlen=14 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password sufficient md5 shadow nullok try_first_pass use_authtok
password required

session  optional revoke
session  required
session  [success=1 default=ignore] service in crond quiet use_uid
session  required

I invalidate my user password forcing them to change it:

# chage -d 0 <user>

when I run the custom application using sudo my /var/log/debug.log produces the following.

pam_unix(validate:account): expired password for user mike (root enforced)
pam_cracklib(validate:chauthtok): bad password: it is WAY too short
pam_unix(validate:chauthtok): password changed for mike
share|improve this question
up vote 2 down vote accepted

This is because sudo runs your commands as root.

If you check man pam_cracklib you'll see the following

       The module will return error on failed check also if the user
       changing the password is root. This option is off by default which
       means that just the message about the failed check is printed but
       root can change the password anyway. Note that root is not asked
       for an old password so the checks that compare the old and new
       password are not performed.

So, what you need to do is change your pam_cracklib.soline to say

password requisite debug retry=3 minlen=14 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 enforce_for_root

Having looked at the source it does the following at line 804 (on Fedora 20 anyhow)

  if (getuid() || options.enforce_for_root || (flags & PAM_CHANGE_EXPIRED_AUTHTOK))

So, it checks the real UID of the caller and enforces the change or not depending on whether the the real UID is 0.

So, you should simply be able to setuid your binary and make sure root owns it, then it will be able to change password and enforce the cracklib decision. setuid'ing your binaries only sets the effective uid to 0, not the real one.

share|improve this answer
I did a man on my RHEL system since it did not work for me, and apparently that is not one of my supported options :( Is there another way to authenticate without sudo? I would prefer not to use sudo. Whenever I try it always fails without those permissions. – jnbbender Jan 23 '14 at 20:11
I cant tell you that without knowing what your application does. Try. – Matthew Ife Jan 23 '14 at 20:52
Is it a test you wrote yourself? – Matthew Ife Jan 23 '14 at 21:02
It's amazingly straightforward. It's a test to change the password using PAM.value = pam_start("validate", user, &conv, &pamh); if(value == PAM_SUCCESS) { password = pass; value = pam_acct_mgmt(pamh, 0); if (value == PAM_SUCCESS || value == PAM_NEW_AUTHTOK_REQD) { password = pass; value = pam_chauthtok(pamh, PAM_SILENT); } } } – jnbbender Jan 23 '14 at 21:08
If I could get my pam_cracklib source code on my system I might be able to add the enforce_for_root option from pam_cracklib. Unfortunately I can't do that. – jnbbender Jan 23 '14 at 21:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.