Bug 67408 - 'su -' fails on expired passwords -- even as root on system-accounts
'su -' fails on expired passwords -- even as root on system-accounts
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Eido Inoue
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-06-24 12:58 EDT by Enrico Scholz
Modified: 2007-04-18 12:43 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-27 15:22:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2002-06-24 12:58:52 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):


How Reproducible:


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'

Actual Results:

4. asks for a new passwd and fails
Comment 1 Bernhard Rosenkraenzer 2002-07-01 07:52:24 EDT
What does your /etc/pam.d/su say?
Comment 2 Enrico Scholz 2002-07-01 08:01:31 EDT
---- /etc/pam.d/su
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

---- /etc/pam.d/system-auth
# 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
shadow nis
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
Comment 3 Phil Knirsch 2002-07-12 06:38:40 EDT
Looking into it right now.

Read ya, Phil
Comment 4 Phil Knirsch 2002-07-15 10:29:44 EDT
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
Comment 5 Phil Knirsch 2002-07-23 04:17:00 EDT
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
Comment 6 Nalin Dahyabhai 2002-08-23 00:09:35 EDT
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.
Comment 7 Enrico Scholz 2002-08-23 06:55:26 EDT
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.

Perhaps adding

| account       sufficient   /lib/security/pam_rootok.so

to /etc/pam.d/su and extending pam_rootok.so might be a better solution?
Comment 8 Jay Turner 2002-08-26 09:29:22 EDT
Reopening this to address issues expressed in the last post.
Comment 9 Preston Brown 2002-08-28 23:49:57 EDT
enrico:  this isn't really a new problem in Milan, is it?
Comment 10 Enrico Scholz 2002-08-29 20:32:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.