Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686440 - clarify behavior of chage in the manual page
Summary: clarify behavior of chage in the manual page
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: shadow-utils
Version: 7.6
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Martin Zelený
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-07 13:18 UTC by amitkuma
Modified: 2019-04-16 11:43 UTC (History)
4 users (show)

Fixed In Version: shadow-utils-4.6-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1691751 (view as bug list)
Environment:
Last Closed: 2019-03-19 11:00:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description amitkuma 2019-03-07 13:18:48 UTC
Description of problem:

Removed 'x' for user 'test2' from /etc/passwd, but password string is not removed from /etc/shadow.

# cat /etc/passwd|grep test2
test2::1001:1001::/home/test2:/bin/bash

# cat /etc/shadow|grep test2
test2:$6$cELtwRPK$s7OZEKzuI3KRE5fh5iaBi1lEwUVqKC5TqDXVc0qqDpyEeAW1dHLNUhEhHc5NUg7GXVI9nm7Qs/E7k7e6q/tqQ0:17962:0:99999:7:::


Issue: 
- chage tool should inform something about password entry for user maybe:
 a. For this user 'x' is not specified inside '/etc/passwd'. Please correct /etc/passwd entry.
 OR
 b. Password entry will not take effect, since /etc/passwd 'x' is missing
 OR 
 c. Some other relevant information.

************************************************************
# chage -l test2
Last password change					: Mar 07, 2019
Password expires					: never
Password inactive					: never           <<<<<<<<<<
Account expires						: never
Minimum number of days between password change		: 0  
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

chage should provide some information, Example:
a. /etc/shadow does not contain 'x' field. Password will not be checked or something.
*************************************************************


Related bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1686436


Version-Release number of selected component (if applicable):
shadow-utils-4.1.5.1-25.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
When 'x' is not present in /etc/passwd, chage tool should provide some information that user is configured for not using password during login, or some other relevant information.

Additional info:

Comment 2 Tomas Mraz 2019-03-07 13:49:00 UTC
Removal of x from /etc/passwd is simply indication that the given user does not use /etc/shadow anymore. Do not do that if that is the intention. This is one of the most basic things about unix account system and I do not think it is chage role to educate sys admins about such stuff.

Comment 5 Daniele Palumbo 2019-03-07 23:17:35 UTC
Human errors may exists unfortunately.
And i have faced it.

That said, if pam_unix would not be standard for nullok on RHEL, i may eventually agree with you, but unfortunately:
nullok is still the standard in RHEL8, but can be disabled: https://bugzilla.redhat.com/show_bug.cgi?id=1637936
nullok is and will remain the standard in RHEL7: https://bugzilla.redhat.com/show_bug.cgi?id=1640731

Given that behavior, and given the interconnection with
* chage (this bug)
* passwd(1) -S (https://bugzilla.redhat.com/show_bug.cgi?id=1686436)
Both tools report that a password is set, and this is true, but do not report that a null password can be used.

Moreover, even if i fully agree that 2nd field of passwd must not be empty, passwd(5) say that this is allowed:
"""
If the encrypted password, whether in /etc/passwd or in /etc/shadow, is an empty string, login is allowed without even asking for a password. Note that this functionality may be intentionally disabled in applications, or configurable (for example using the "nullok" or "nonull" arguments to pam_unix.so).
"""

Therefore, i think that both passwd(1) and chage(1) must be modified in order to inform the OS Admin of what is happening.
Worst then having a server not secure, is to think that the server is secure, while it is not.

Comment 6 Tomas Mraz 2019-03-08 09:04:39 UTC
No, chage is not the tool. pwck is the tool that reports such inconsistencies.

I am sorry but this will not be changed.

Comment 7 Daniele Palumbo 2019-03-08 14:13:41 UTC
given this test:
test ~ # pwck /etc/passwd
user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
pwck: no changes
test ~ # grep ^root /etc/passwd
root::0:0:root:/root:/bin/bash
test ~ #

Do you agree on opening a bug against pwck?
Nevertheless, according to passwd(5), this not an inconsistency, so i am curious on why you are suggesting to have pwck as tool that reports such inconsistencies. Mind to provide some more explanation?

Comment 8 Daniele Palumbo 2019-03-08 14:39:38 UTC
About chage,
my feeling is that chage is potentially reporting wrong informations.

chage(1)
"""
chage - change user password expiry information
[...]
The chage command changes the number of days between password changes and the date of the last password change. This information is used
by the system to determine when a user must change his/her password.
"""

Let me focus on:
"This information is used by the system to determine when a user must change his/her password."
lack of 2nd field of passwd, would result in chage is reporting wrong information, because the password must not be changed as not validated.

Would you agree on that?

Comment 9 amitkuma 2019-03-12 13:11:51 UTC
Dear Tomas Mraz,

Can you kindly find some time to address Daniele's questions in Comment7,8.
Thanks

Comment 10 Tomas Mraz 2019-03-18 11:27:04 UTC
Inconsistent situation is when you do not have x in /etc/passwd entry and there is entry in /etc/shadow.

The 'Password inactive' field does not mean whether password is removed but it marks date when user won't be able to change his password anymore after the password expiration.

This is what I see:

# grep testsha /etc/shadow
testsha:$6$GLlQc1.d$gWZ4c45eebhOTQ9gQc44KWplMba5I/HhT78bBrFLNORK/rfAISxNQlR.0jmt2lCKT6xe5ZQ4aSinWiKTdDmtz.:17973:0:99999:7:::

# grep testsha /etc/passwd
testsha::1000:1000::/home/testsha:/bin/bash

# pwck
user testsha has an entry in /etc/shadow, but its password field in /etc/passwd is not set to 'x'

chage report is correct as it reports things from the /etc/shadow.

On the other hand I see a problem with pam_unix that it ignores the /etc/shadow for the password expiration check if the x is missing in /etc/passwd entry.

I cannot reproduce the issue with passwd having no effect when changing the password of such user - it properly updates /etc/passwd and adds x in the password hash field.

Comment 11 amitkuma 2019-03-18 11:51:15 UTC
Dear tomas,
I have furnished system-auth, password-auth, passwd, sshd on case 1689860.

Comment 12 Tomas Mraz 2019-03-19 11:00:35 UTC
I still do not see any problem with chage here.

Comment 13 Daniele Palumbo 2019-03-21 16:32:22 UTC
Tomas, 

i understand your comment, really.
But i feel that the implication of a lack of more verbose output are not considered.
And given that sys admins should not be educated, but neither getting misleading information, chage manual is not reflecting what you are writing in that bz.

From RHEL7 man

"""
NOTE
       The chage program requires a shadow password file to be available. <--- man does not say that it takes information out only from shadow file

       The chage command is restricted to the root user, except for the -l option, which may be used by an unprivileged user to determine when
       his/her password or account is due to expire. 

CONFIGURATION
       The following configuration variables in /etc/login.defs change the behavior of this tool:

FILES
       /etc/passwd <--- here the file is required, and clear that this is not for x (or lack of) but is not specified.
           User account information.

       /etc/shadow
           Secure user account information.

EXIT VALUES
       The chage command exits with the following values:

       0
           success

       1
           permission denied

       2
           invalid command syntax

       15 <--- a valid exit code in case of 
           can't find the shadow password file

SEE ALSO
       passwd(5), shadow(5). <--- both files are referred
"""


To get out of the problem, i would suggest either to:
a) say in the output, as pwck do, that password is set but x is not set in the passwd file
b) man change in order to reflect the fact that chage does not consider at all if the password is looked up.

e.g. in NOTE (even if i feel this to be more DESCRIPTION), in place of:
"""
       The chage program requires a shadow password file to be available.

       The chage command is restricted to the root user, except for the -l option, which may be used by an unprivileged user to
       determine when his/her password or account is due to expire.
"""

Insert the following:
"""       
       The chage program will report only the information from the shadow password information. This imply that a configuration
       that block a user login (e.g.: "*" or empty second field of passwd(5)) or other authentication source
       (e.g.: LDAP) will not be looked up.

       The chage command is restricted to the root user, except for the -l option, which may be used by an unprivileged user to
       determine when his/her password or account is due to expire.

       The chage programm will not report any inconsistency or skip. pwck(1) may be useful to verify such events.
"""

Of course this is a suggestion, feel free to change it as your willing.

HTH

Comment 14 Tomas Mraz 2019-03-22 09:08:07 UTC
OK, the manual page improvement can be done.


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