Red Hat Bugzilla – Bug 67408
'su -' fails on expired passwords -- even as root on system-accounts
Last modified: 2007-04-18 12:43:35 EDT
Description of Problem:
When running 'su - <sysaccount>' I will be asked for a new password:
| [root@morden root]# su - smmsp
| You are required to change your password immediately (password aged)
| Changing password for smmsp
| (current) UNIX password:
| [root@morden root]# finger smmsp
| Login: smmsp Name: (null)
| Directory: /var/spool/mqueue Shell: /sbin/nologin
| ... ~~~~~~~~~~~~~
| [root@morden root]# LANG=C chage -l smmsp
| Minimum: 0
| Maximum: 90
| Warning: 14
| Inactive: -1
| Last Change: Mar 13, 2002
| Password Expires: Jun 11, 2002
| Password Inactive: Never
| Account Expires: Never
This becomes a problem since all system-accounts (postgres, apache, ...) are
created with normal expire time in the %post scriptlets. When started in the
init-scripts with 'su - <account> -c <cmd>' the new password will be queried and
the start fails because there is no input.
I think it is not a problem with the %post scriptlets because the accounts do
not have a password and it can not expire therefore. Instead of, it is a 'su'
or 'pam' issue (please reassign if needed).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. define 'PASS_MAX_DAYS 1' in /etc/login.defs
2. install postgresql on a fresh system (without user postgres)
3. wait 2 days
4. 'service postgresql start'
4. asks for a new passwd and fails
What does your /etc/pam.d/su say?
auth sufficient /lib/security/pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient /lib/security/pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required /lib/security/pam_wheel.so use_uid
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_xauth.so
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth required /lib/security/pam_deny.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok md5
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
Looking into it right now.
Read ya, Phil
OK, it's quite clearly a pam problem, so i'm reassigning it.
The module pam_unix_acct doesn't handle aging of accounts with empty passwords
as one would intuitively think it should.
Read ya, Phil
I'm reassigning this bug to the actual owner of PAM. Have been in discussion
with him and proposed a solution but let him take care of it.
Read ya, Phil
The pam_unix module can't know whether an account has an empty (or rather, a
locked) password because it's a system account or because the user legitimately
has no password. It seems to me that we shouldn't be using aging when we create
system accounts, which should be the case in shadow-utils-20000902-11 and later.
I do not think that this is a shadow-utils issue only because a changed
shadow-utils affects newly created accounts only. Existing RH 6 or 7 systems may
have dozens of expired system-accounts and there should be exists a way to use
them after an upgrade also.
| account sufficient /lib/security/pam_rootok.so
to /etc/pam.d/su and extending pam_rootok.so might be a better solution?
Reopening this to address issues expressed in the last post.
enrico: this isn't really a new problem in Milan, is it?
Mmmh, I saw the broken reboot after upgrading pam/sh-utils so I thought it was
introduced in the beta.
After your question I tried it on RH 7.3 and it happens there also. Probably the
upgrade happened when the accounts expired so it is really an old problem.