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 pam_env.so
auth required pam_tally.so onerr=fail deny=3
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account required pam_tally.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so debug retry=3 minlen=14 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
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
Best Answer
This is because
sudo
runs your commands as root.If you check
man pam_cracklib
you'll see the followingSo, what you need to do is change your
pam_cracklib.so
line to sayHaving looked at the pam_cracklib.so source it does the following at line 804 (on Fedora 20 anyhow)
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.