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): util-linux-2.24-0.1.fc20.x86_64 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 - Password: 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
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
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.
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 ? http://linux-pam.org/Linux-PAM-html/sag-pam_lastlog.html silent Don't inform the user about any previous login, just update the /var/log/lastlog file. noupdate Don't update any file. For me, it tells to update /var/log/lastlog, but then it tells to not update the files ?
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.
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.
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.
thanks for your answer. Will experiment with updating wtmp or not :)
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: #%PAM-1.0 # 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.
Just for reference, this is happening and GDM logins with a Fedora 20 clean install (no upgrade), See bug 1047077
I did something that fix it, but just after sometime, one reboot ? I think it was : authconfig --updateall
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.