How do I disable or modify pam's password requirements?

Question

I'm using Fedora 19. By default it's setup with pam to disable bad passwords, like "password". This is good. Trying to change this default is infuriating. This is a box for testing internal stuff, not connected to the internet, nor any machine that is. Bad passwords facilitate the testing process. Alternatively, how the hell do you change password requirements at all??

system-auth

man pam_cracklib has some great examples of setting different password requirements. So I open up /etc/pam.d/system-auth, which is where you see lines like:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
password    requisite     pam_pwquality.so try_first_pass retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

*headdesk*. In my experience, warnings like this mean your changes are wiped every time the package manager is run and/or randomly.

authconfig

So...authconfig is the next step. I look for all files named "authconfig". /etc/sysconfig/authconfig looks promising. And, no warning at the top about destroying my edits on a whim. I find this line USEPWQUALITY=yes and change it. Now I run:

# authconfig --test
<snip>
pam_pwquality is enabled (try_first_pass retry=3 authtok_type=)
<snip>

wtf. So let's read man authconfig a little closer. Oh! Looks like that file isn't read by authconfig, it's changed. So....how do you configure authconfig? The manual suggests system-config-authentication, which I install and doesn't provide anything resembling a checkbox to disable pam_pwquality. The next suggestion from the manual is command line options. Great! I love command line tools. Only, none of the documented command line options disable pam_pwquality.

pwquality.conf

Thanks to Aaron's answer, I learned that a couple years ago fedora decided to make /etc/security/pwquality.conf the place to configure password quality requirements. Unfortunately, as documented in the file and in man 5 pwquality.conf, there (1) isn't a way to disable the dictionary checking and (2) can't set allowed password length below six.

Answer 1

After a cursory look at the source code in /usr/sbin/authconfig and /usr/share/authconfig/authinfo.py:

• The man page is incomplete, the complete list of options accepted by the script is in authconfig --help
• Everything can be overridden on the command-line (even /etc/security/pwquality.conf settings like password minimum length), except pwquality itself. IMHO, this is a bug and should be reported.

• From authinfo.py line 2489 and 2156:

  def read(self):
    self.readSysconfig()
    ...
    self.readPAM(ref)
    ...
  

  First readSysconfig reads /etc/sysconfig/authconfig ; then what you put there is overwritten by readPAM with what is in /etc/pam.d/* (especially password_auth* and system_auth*):

    if module.startswith("pam_cracklib") or module.startswith("pam_pwquality"):
       self.setParam("enablePWQuality", True, ref)
  

---

TL;DR: for the options which are not overriden (or cannot be), the settings are taken from the current configuration including files which are tagged autogenerated. To make it work, edit /etc/sysconfig/authconfig and remove lines shown by grep -E pwq\|crack /etc/pam.d/*

---

Edit: There is a second bug, which makes the advice above still not work: line 2248:

    # Special handling for pam_pwquality and pam_passwdqc: there can be
    # only one.
    if self.enablePWQuality and self.enablePasswdQC:
            self.setParam("enablePasswdQC", False, ref)
    if not self.enablePWQuality and not self.enablePasswdQC:
            self.setParam("enablePWQuality", True, ref)

You have to chose one of the two implementation of quality control, or one will be chosen for you ! Combined with first bug, this makes it impossible to disable.

Answer 2

You can take manual control over your system-auth file. Create a new file (you could start by copying system-auth-ac), and change the system-auth symlink to point at the new file.

This makes it your responsibility to update this part of your PAM configuration, as authconfig will no longer touch the symlink or the file it points to. However, authconfig will still update the system-auth-ac file, so you can continue to use that as a reference if you need to. With some cleverness, you may even be able to include it into your local copy, but how to do that is beyond the scope of this question.

You should also check for other symlinks, such as password-auth. You may need to give them the same treatment.

---

From the authconfig(8) manpage, under Files:

/etc/pam.d/system-auth
    Common PAM configuration for system services which include it using
    the include directive. It is created as symlink and not relinked if
    it points to another file.

/etc/pam.d/system-auth-ac
    Contains the actual PAM configuration for system services and is the
    default target of the /etc/pam.d/system-auth symlink. If a local
    configuration of PAM is created (and symlinked from system-auth
    file) this file can be included there. 

So if system-auth is a file, then authconfig changes it to link to system-auth-ac. But if system-auth is a symlink, then authconfig leaves it alone.

Answer 3

It looks to be configurable through /etc/security/pwquality.conf

Source: https://fedoraproject.org/wiki/Features/PasswordQualityChecking

Answer 4

You can still change from the command line. You get a warning, but it will let you set a password that is too short, as well as one that does not meet complexity rules.

Answer 5

I just found this question based on a related search, and I think I have an answer for you.

Fedora creates symbolic links to the authconfig generated files. i.e.. system-auth links to system-auth-ac. If you make system-auth its own file, then theoretically any future changes made by auth-config will still update system-auth-ac but leave your modified files unchanged.

It's actually quite elegant, but I only discovered it when wondering what the *-ac files did.