Bug 88190 - modifying a user created with shadow-utils causes passwd to expire in 0 days [has patch]
Summary: modifying a user created with shadow-utils causes passwd to expire in 0 days ...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-users
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
: 89758 91452 101463 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-07 15:04 UTC by jmccann
Modified: 2015-01-14 23:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-09-16 23:12:35 UTC

Attachments (Terms of Use)
moves form-fill to after is-expire-enabled check (2.38 KB, patch)
2003-05-08 02:51 UTC, Matthew Miller
no flags Details | Diff

Description jmccann 2003-04-07 15:04:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Description of problem:
After I used redhat-config-users to add a user to a group the account was marked
as expired.  This prevents the user from logging back in.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. redhat-config-users
2. add user NAME to GROUP
3. exit

Actual Results:  Added to group but account expired.

Expected Results:  Added to group.

Additional info:

The default shadow entry for a new user is:

The corrupted shadow entry is:

Comment 1 Matthew Miller 2003-05-08 01:52:32 UTC
*** Bug 89758 has been marked as a duplicate of this bug. ***

Comment 2 Matthew Miller 2003-05-08 02:30:07 UTC
It's worse than that -- you don't actually have to change a group or anything.
Just double click a user to open their userProperties window, and press okay,
and the max password lifetime field will get set to zero if it was previously 99999.

Here's what's going on: redhat-config-users has a check to see if password
expiration is enabled. It does this by checking if both the password minimum
lifetime and the password expiration warning time are set to anything but -1.

If either of these has a different value -- and a different value is the
/etc/login.defs default -- then it considers password expiration to be enabled.
It also checks the password invalid field, but for some reason that I'm not
clear on, this value can be either -1 or empty and either way, password
expiration is considered active. (Not sure why this one is different -- the code
in userProperties.py is the same as the others.) 

In each case, whenever the value is other than -1, the corresponding field in
the password info tag is filled out with that value. If it *is* -1 (or null, in
the case of invalid-days), it gets left at the default value of '0'.

But then, it does something strange. It tries to make a fourth check, this time
to see if password max lifetime is anything but 99999. In other words, the
intention to disable password expiration if the four fields are set to
-1:99999:-1:-1. Here's the flaw, though: when the value is the magic number
99999, the form field is never filled in! It's left at its default value of 0!

This is fine when all the other fields are -1, since then password expiration is
considered disabled, the form is greyed out, and nothing happens. But if the max
lifetime *is* 99999 but any of the other fields are set, the form gets activated
but the 99999 is written as 0, and then written out that way. Ooops!

I tried changing the login.defs entries for PASS_MIN_DAYS and PASS_WARN_AGE to
-1 as a workaround, but this doesn't work since that just causes the fields to
be null. However, setting the default PASS_MAX_DAYS to 99998 *does* work, albeit
in a sort of silly way. Of course, I'm not suggesting that kludge as a solution
-- the right thing to do is to separate the filling out of the form fields from
the logic to decide if expiration is active. (First decide, then set the form.)

Comment 3 Matthew Miller 2003-05-08 02:51:34 UTC
Created attachment 91549 [details]
moves form-fill to after is-expire-enabled check

Comment 4 Brent Fox 2003-09-16 23:12:35 UTC
Should be fixed in redhat-config-users-1.1.17-1.  Long term, the UI in this
notebook tab should be improved, but this fix should work in the meantime.

Comment 5 Brent Fox 2003-10-14 01:08:15 UTC
*** Bug 101463 has been marked as a duplicate of this bug. ***

Comment 6 Brent Fox 2003-12-01 20:32:26 UTC
*** Bug 91452 has been marked as a duplicate of this bug. ***

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