Bug 1021108 - su always report failed attempts even after a success
su always report failed attempts even after a success
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-19 09:16 EDT by Heldwin
Modified: 2015-06-29 08:40 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-06-29 08:40:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Steps done as exemple (823 bytes, text/plain)
2013-10-19 09:16 EDT, Heldwin
no flags Details

  None (edit)
Description Heldwin 2013-10-19 09:16:21 EDT
Created attachment 813987 [details]
Steps done as exemple

Description of problem:
When using the command 'su' on my terminal, if I enter a wrong password, it gets logged.

If I login successfully using 'su', I get the normal message:
"Last failed login: Sat Oct 19 14:19:51 CEST 2013 on pts/0
There were 1 failed login attempt since the last successful login."

If I exit 'su' and do again 'su', I still get:
"Last failed login: Sat Oct 19 14:19:51 CEST 2013 on pts/0
There were 1 failed login attempt since the last successful login."

But I did a successfull login before that, so this message shouldn't appear.

It looks like, the failed attempts are loggeg using 'su', but doesn't seem to be "resetted" after a success. That happens only if you use 'su'.

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

How reproducible:
Always on my system

Steps to Reproduce:
1. su - (with a bad password)
2. exit
3. su - (with a correct password)
4. exit
5. su - (with a correct password)
6. can repeat steps 1 to 5

Actual results:
Should always report the failed attempts since last successfull login

Expected results:
That the last failed attempts are cleared after a successfull login.

Additional info:
If you enter root on a TTY, the failed attempts are cleared.

/var/log/lastlog never updates the date of the last successfull login if using 'su'. Would it be possible the checks are done compared to the last login date of that file ?

[xxx@yyy ~]$ LANG=C date
Sat Oct 19 15:13:16 CEST 2013
[xxx@yyy ~]$ LANG=C su -
Last failed login: Sat Oct 19 15:07:36 CEST 2013 on pts/1
There were 12 failed login attempts since the last successful login.
[root@yyy ~]# LANG=C lastlog | grep root
root             tty2                      Sat Oct 19 13:58:21 +0200 2013
Comment 1 Heldwin 2013-10-19 09:24:42 EDT
If you delete and recreate /var/log/btmp, the failed attemps message doesn't show anymore, even if the logs attempts are logged in /var/log/secure
Comment 2 Karel Zak 2013-10-21 08:38:51 EDT
It seems like inconsistent PAM configuration. We use pam_lastlog to print the warning message ("Last failed login:"), but pam_lastlog is not configured to update the lastlog file. 

For su(1) the all lastlog behaviour should be controlled by PAM configuration only.

Note that we always write to the btmp file for security reasons independently on PAM configuration.
Comment 3 Heldwin 2013-10-21 14:46:32 EDT
ok thanks.

If I change this line in /etc/pam.d/postlogin:

#session     optional      pam_lastlog.so silent noupdate showfailed
session     optional      pam_lastlog.so silent showfailed

I get what I call a normal behaviour (but correct me if I am wrong).

=> it tells me if a failed attempt happened before I successfully login, and the next time, it doesn't tell me it because no failed attempt was done between my 2 success.

I don't think silent and noupdate can be used together ?


Don't inform the user about any previous login, just update the /var/log/lastlog file. 

Don't update any file. 

For me, it tells to update /var/log/lastlog, but then it tells to not update the files ?
Comment 4 Tomas Mraz 2013-10-22 03:01:18 EDT
The documentation is slightly confusing but silent and noupdate can be used together although it makes sense only with showfailed. It means that it will just show failed attempts and not do anything else.

But what should be actually used is nowtmp silent showfailed so it does not update wtmp but only lastlog.
Comment 5 Heldwin 2013-11-23 06:44:09 EST
Sorry for the delay. 

Tested with the change you told, it works as I wanted, but I am not sure I understand why wtmp shouldn't be updated.
Comment 6 Tomas Mraz 2013-11-25 03:02:28 EST
wtmp should not be updated for su, because su sessions are not full login sessions. But of course you can choose it to be updated.
Comment 7 Heldwin 2013-11-27 16:06:06 EST
thanks for your answer.

Will experiment with updating wtmp or not :)
Comment 8 Jerry 2013-12-28 11:52:06 EST
I saw the same behavior as Heldwin.  I did the same change in /etc/pam.d/postlogin:

#session     optional      pam_lastlog.so silent noupdate showfailed
session     optional      pam_lastlog.so nowtmp silent showfailed

and noticed that when I logged into a terminal, the last login time was the current time (the time I had just logged in).  This wasn't satisfactory, so I looked in the postlogin file and saw the header:

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.

So I ran

authconfig --updateall

That seems to have corrected the errors I was experiencing.  I had run FedUp to upgrade to Fedora 20 from Fedora 19.  Perhaps there were ghosts left behind from the upgrade.

I'll post an update if I see any changes.
Comment 9 Robert Marcano 2013-12-28 16:04:42 EST
Just for reference, this is happening and GDM logins with a Fedora 20 clean install (no upgrade), See bug 1047077
Comment 10 Sergio Monteiro Basto 2014-04-30 04:00:06 EDT
I did something  that fix it, but just after sometime, one reboot ? 
I think it was : 

authconfig --updateall
Comment 11 Fedora End Of Life 2015-05-29 05:35:46 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2015-06-29 08:40:06 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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