You are not logged in.
I see this a lot: Error opening /var/log/faillog
$ journalctl -b -p3
-- Logs begin at Mon 2016-05-16 21:40:56 EDT, end at Wed 2016-07-27 22:30:13 EDT. --
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:auth): Error opening /var/log/faillog for update
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:auth): Error opening /var/log/faillog for read
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:auth): Error opening /var/log/faillog for update
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:auth): Error opening /var/log/faillog for read
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:setcred): Error opening /var/log/faillog for update
Jul 27 22:22:26 x99 kcheckpass[5682]: pam_tally(kde:setcred): Error opening /var/log/faillog for update
I don't see much about it on Google.
$ ls -la /var/log/faillog
-rw------- 1 root root 32096 Jul 27 20:07 /var/log/faillog
What does the error really indicate is not working? How can I resolve it?
Last edited by MountainX (2018-06-22 01:12:44)
Offline
It looks like the user used by "kcheckpass" (whatever that is, I'm not sure as I do not use KDE) does not have permissions to either read or write to /var/log/faillog. Should it?
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
Thanks for the reply. There is no user named kcheckpass , but man kcheckpass gives some info:
kcheckpass - KDE's authentication program
Any program, such as a screensaver with a lock option, that needs to authenticate a user, can use kcheckpass. kcheckpass is a simple setuid program that returns 0 if the user has been authenticated, and 1 if not. Other programs that need user authentication can use kcheckpass witout having setuid status, thus simplifying programs and enhancing system security.
OPTIONSkcheckpass takes no arguments. It reads the password from stdin.
SECURITY
kcheckpass must be setuid on systems that use shadow passwords.
kcheckpass must be setuid on systems that use shadow passwords.
Maybe that last line is the clue. How would I do that?
Offline
I wonder if the requirement that it must be setuid is still valid when it is using pam as it seems to be from the journal messages.
The system wide /etc/pam.d/system-auth uses pam_unix which already has a setuid helper unix_chkpwd for that purpose.
Would also look at the man pages for pam_tally and pam_tally2
Offline
To setuid you can do
chmod +s /usr/lib/kcheckpass
Another way to fix it is to change to using pam_tally2 which does not have this problem. This is probably a better solution. Edit the file /etc/pam.d/system-login and replace where it says pam_tally.so with pam_tally2.so.
Last edited by samcv (2016-08-12 13:41:21)
Offline
@samcv changing the one occurrence of oam_tally.so to pam_tally2.so in /etc/pam.d/system-login would give
auth required pam_tally2.so onerr=succeed file=/var/log/faillog
Should not both options also be removed as well:
The onerr=succeed option because its previous inclusion was for when /var/log/faillog could not be accessed and and pam_tally2 handles that by returning PAM_IGNORE.
The file=var/log/faillog because as the man page for pam_tally2 notes it is not compatible with the file log format of /var/log/faillog so faillog would no longer function if I understand it correctly.
I agree though that switching to pam_tally2.so seems more reasonable than the setuid in principal provided MountainX only want to suppress the error messages and not detect failed login attempts in all cases.
Offline
@loqs yes you are right. The man page says to use /var/log/tallylog and that this is the default for pam_tally2.
Edit: You can create /var/log/tallylog with the correct permissions by doing the following:
touch /var/log/tallylog
chmod 600 /var/log/tallylog
Last edited by samcv (2016-08-12 15:53:29)
Offline