Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1530659 - message of expired password in RHEL 7.5 Beta
message of expired password in RHEL 7.5 Beta
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-settings-daemon (Show other bugs)
7.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ray Strode [halfline]
Desktop QE
: Regression
: 1535651 1543537 (view as bug list)
Depends On:
Blocks: 1527213
  Show dependency treegraph
 
Reported: 2018-01-03 10:20 EST by Oliver Haessler
Modified: 2018-05-17 10:39 EDT (History)
8 users (show)

See Also:
Fixed In Version: gnome-settings-daemon-3.26.2-7.el7 accountsservice-0.6.45-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 09:10:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
password expired notification (888.33 KB, image/png)
2018-01-03 10:20 EST, Oliver Haessler
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0770 None None None 2018-04-10 09:11 EDT

  None (edit)
Description Oliver Haessler 2018-01-03 10:20:24 EST
Created attachment 1376469 [details]
password expired notification

Description of problem:
After a fresh installation of RHEL CSB (Red Hat internal config for employees), a notification pops up saying that a password has expired. Clicking on the notification does not have an effect, and it doe snot say at all which password has expired (log in to gnome is via sssd and kerberos password, so it can not be this). This happens only with users that use sssd. If I log in as root I do not get the error.

This did not happen on RHEL 7.4 or before

Version-Release number of selected component (if applicable):
gnome-shell-3.26.2-2.el7.x86_64

How reproducible:
Fresh installed RHEL CSB

Steps to Reproduce:
1. Log in as user with a fresh install (user needs to set up to auth via sssd)


Actual results:
Notification that only shows that the password has expired (no further info)

Expected results:
No notification, or a notification with more context.
Comment 2 Matěj Cepl 2018-01-04 12:03:14 EST
> This happens only with users that use sssd.

I don't think this is true. I have no sssd running and sssd.service is disabled, and yet I have the same meaningless message showing up.

Using RHEL-7.5 Nightly.
Comment 3 Tomas Pelka 2018-01-17 16:16:36 EST
*** Bug 1535651 has been marked as a duplicate of this bug. ***
Comment 5 Ray Strode [halfline] 2018-01-29 13:41:51 EST
probably a problem in the feature added in bug 1314443.

can you guys post the results of

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy

(run as the user seeing the problem)
Comment 6 Matěj Cepl 2018-01-30 09:40:07 EST
(In reply to Ray Strode [halfline] from comment #5)
matej@mitmanek: ~$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)
matej@mitmanek: ~$
Comment 7 Matěj Cepl 2018-01-30 09:44:50 EST
(In reply to Ray Strode [halfline] from comment #5)
> probably a problem in the feature added in bug 1314443.

If it is so, then I would say it is a horrible UI bug. This message essentially tells me “There is something seriously wrong with the security of your system, but I won’t tell you what, and so you won’t know what to do about it.” That looks to me like an attempt to torture users.
Comment 8 Ray Strode [halfline] 2018-01-30 10:17:59 EST
Problem seems to be this code:

        if (manager->priv->last_change_time <= 0) {•
                password_already_expired = TRUE;•
                goto out;•
        }•

it should instead say:

        if (manager->priv->last_change_time == 0) {•
                password_already_expired = TRUE;•
                goto out;•
        }•
Comment 12 Ray Strode [halfline] 2018-02-07 09:10:34 EST
Oliver, can you post the results of:

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy

(run as the user seeing the problem)
Comment 13 Oliver Haessler 2018-02-07 09:25:05 EST
[ohaessle@ohaessle Desktop]$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
[ohaessle@ohaessle Desktop]$
Comment 14 Tomas Pelka 2018-02-07 09:58:50 EST
I know I was not asked :) but getting different output

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)
Comment 15 Tomas Pelka 2018-02-07 09:59:23 EST
(In reply to Tomas Pelka from comment #14)
> I know I was not asked :) but getting different output
> 
> $ gdbus call --system --dest org.freedesktop.Accounts --object-path
> /org/freedesktop/Accounts/User$(id -u) --method
> org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
> (int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)

Oh and I'm not seeing the issue.
Comment 16 Ray Strode [halfline] 2018-02-07 10:35:30 EST
(In reply to Oliver Haessler from comment #13)
> [ohaessle@ohaessle Desktop]$ gdbus call --system --dest
> org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id
> -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
> (int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
> [ohaessle@ohaessle Desktop]$

Hmm, unless I'm misunderstanding something you're shadow file says:

This user last changed their password today.  We allow them to change it again right away if they want.  We also require them to change it today.  We don't warn  ahead of time that they need to change it.  The account will go inactive today.  The password expired Jan 1, 1970.

It seems like the banner is "right" unless i'm misunderstanding something.

I'm confused why you aren't getting forced to change your password at log in time, though, so maybe I am misunderstanding something.

Can you post your /etc/pam.d files?
Comment 17 Ray Strode [halfline] 2018-02-07 10:38:01 EST
also can you post the output of:

╎❯ sudo getent shadow $(whoami)
Comment 18 Ray Strode [halfline] 2018-02-07 10:41:25 EST
(make sure your password is throwaway before doing comment 17)
Comment 19 Oliver Haessler 2018-02-07 10:43:27 EST
well, the username ohaessle is not on the shadows file, as this is a user set up with sssd. Maybe thats the issue here?

The user us created during set up of the machine, and uses kerberos auth to authenticate
Comment 20 Ray Strode [halfline] 2018-02-07 11:10:02 EST
so the problem, I guess, is we're not returning a NOT_SUPPORTED error to control-center in the case that the shadow file is unavailable.
Comment 21 Ray Strode [halfline] 2018-02-07 11:11:59 EST
(i mean g-s-d not control-center in comment 20 obviously)
Comment 22 Tomas Pelka 2018-02-08 05:10:33 EST
Oliver does it work for you now?
Comment 23 Ray Strode [halfline] 2018-02-08 11:47:11 EST
*** Bug 1543537 has been marked as a duplicate of this bug. ***
Comment 24 bugreports2005 2018-02-12 06:31:06 EST
In our environment the user database is configured through sssd to use a mix of AD and LDAP. Clients can't see the shadow information.

getent shadow returns without output.
gdbus command from above returns this:
(int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)

As of gnome-settings-daemon-3.26.2-3.el7.x86_64, everyone is getting a notice after login that their password has expired. Which is not nice.

I'm not entirely sure how to obtain the gnome-settings-daemon 3.26.2-7 mentioned above, access.redhat.com seems to only carry 3.26.2-5. Did not try that.
Comment 25 Tomas Pelka 2018-02-12 07:31:25 EST
(In reply to bugreports2005 from comment #24)
> In our environment the user database is configured through sssd to use a mix
> of AD and LDAP. Clients can't see the shadow information.
> 
> getent shadow returns without output.
> gdbus command from above returns this:
> (int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
> 
> As of gnome-settings-daemon-3.26.2-3.el7.x86_64, everyone is getting a
> notice after login that their password has expired. Which is not nice.
> 
> I'm not entirely sure how to obtain the gnome-settings-daemon 3.26.2-7
> mentioned above, access.redhat.com seems to only carry 3.26.2-5. Did not try
> that.

As RHEL7.5 was not released yet so you can get mentioned package only in case you as a customer is part of HTB (High Touch Beta) program or you usually get snapshots too.

Fixed package should be part of Snapshot-3 I guess.

If you want still want to get these fixed packages please contact your TAM or person from CEE (former GSS or support team) you usually communicate with. They should be able to help you. Or you need to wait for RHEL7.5 release date.
Comment 26 Oliver Haessler 2018-02-15 06:47:22 EST
7.5 Snapshot 3 does not have the notification anymore
Comment 27 Tomas Pelka 2018-02-15 06:48:58 EST
Thanks Oliver, moving to verified.
Comment 30 errata-xmlrpc 2018-04-10 09:10:18 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0770

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