Description of problem: after upgrade to audit-libs-0.9.7-1 i am unable to login in text mode (not tested in gdm, but will be probably the same), su ends with bad password (i use localization, so this may not be exact), /var/log/secure has some System error messages like this: Jun 18 13:28:34 wintermute login: FAILED LOGIN SESSION FROM (null) FOR root, System error downgrade to 0.8.2-1 solved the problem. (it actually didn't occur in 0.9.5-1, but this version is no longer available on my mirror) Version-Release number of selected component (if applicable): audit-libs-0.9.7-1 How reproducible: allways Steps to Reproduce: 1. upgrade to audit-libs-0.9.7-1 2. try lo log in Actual results: unable to login, message in /var/log/secure Expected results: successfull login Additional info: none
What version of pam are you using? Do you make your own kernel without CONFIG_AUDITSYSCALL? Do you have /proc/self/loginuid?
Also, could you get a strace of su? I'm interested in the return code from sendto syscall. Thanks.
I use pam-0.79-10 and my current kernel is 2.6.11-1.1290_FC4 from rawhide. I didn't compile it on my own, but i use NVdriver /proc/self/loginuid is present at the moment, but i have already downgraded to older audit-libs. i will try to install the new one again tomorrow to let you know. `strace -f -s4096 su -` result is at http://a.q.cz/strace-su.txt , lines containing my /etc/group and /etc/passwd are removed
Thanks. Just to make sure, is that strace one from a failed session?
Created attachment 115658 [details] output of working audit-libs-0.8.2-1
Created attachment 115659 [details] output of not working audit-libs-0.9.8-1
as stated in https://www.redhat.com/archives/fedora-test-list/2005-June/msg00754.html i have the same problem with audit-libs-0.9.7-1 and audit-libs-0.9.8-1. i have both outputs of "strace su - root" attached above. using pam-0.79-10 and a vanilla 2.6.12 kernel with CONFIG_AUDITSYSCALL enabled. /proc/self/loginuid is present here too.
(In reply to comment #4) > Thanks. Just to make sure, is that strace one from a failed session? yes, sorry for that locale thing... i have compiled audit-0.9.6-1 from srpm and it does the same thing as 0.9.7. since 0.9.5 was ok, the bug appeared in 0.9.6. righc now i'm compiling 0.9.5 and i'll provide strace outputs later..
Regarding comment #3. The kernel is returning EINVAL (the 352 in the recvfrom is the error code in octal). This means that it does not understand message type 1100, which is USER_AUTH. The 1290 kernel is much older than 1369 - which is the default for Fedora Core 4. We put a lot of audit patches into the last few kernels before release. My guess is that is the problem. Could you try booting into the default FC4 kernel and see if that solves your problem? Thanks.
Regarding comment #5, the strace shows that a EPERM is being returned. This means that you weren't root, so pam was told sucess. In comment #6, it shows EINVAL being returned. This means the kernel doesn't understand the message. I don't think our kernel guy was able to get all the message types upstream for 2.6.12. They are slated for inclusion in 2.6.13 and are currently in the mm tree. I think I know how to solve this problem for people running kernels that doesn't have all the patches in place.
(In reply to comment #9) > Could you try booting into the default FC4 kernel and see if that solves > your problem? Thanks. thank you, this is the problem. after booting 1369 everything works fine. only one question... if i log in from text console, i see message printed to stdout: audit(1119198450.962:2): user pid=2242 uid=0 auid=4294967295 msg='PAM authentication: user=root exe="/bin/login" (hostname=?, addr=?, ter minal=tty1 result=Success)' it has actually four lines which have different numbers in brackets after audit. the same messages appear in syslog... thank you for your help, next time i will recompile NVdriver each time new kernel is released :)
(In reply to #11) Thanks for checking this. I am working on a new release 0.9.9 that will let the old kernel work. I just wanted to confirm this was the problem and not SE Linux or something strange. The message that you see is the audit message that was being sent to the kernel. I don't think it should be coming out on the terminal, though. I will follow up see if I can solve this problem, too.
(In reply to comment #12) > Thanks for checking this. I am working on a new release 0.9.9 that will let the > old kernel work. I just wanted to confirm this was the problem and not SE Linux > or something strange. imho SE Linux is strange itself... :) at least for me... im going to check it with latest kernel available - 1383 looking forward to 0.9.9 > The message that you see is the audit message that was being sent to the kernel. > I don't think it should be coming out on the terminal, though. I will follow up > see if I can solve this problem, too. can i help you by sending some strace output or so?
(In reply to comment #13) I don't need a strace at this point. The reason that you are getting the print out on the screen has 2 reasons. I found that user space messages were not getting filtered based the audit_enabled variable inside the kernel and posted a kernel patch last week to the linux-audit mail list. This means that audit messages could show up even if the kernel was not supposed to be generating any audit messages. The other issue is that when the audit daemon is not registered with the kernel, the kernel sends the messages to syslog instead. The priority of the message is KERN_ERR, which seems to be high enough that syslogd sends it to the screen as well as the disk. User space messages should not get that priority level. They should be more like LOG_INFO so that they can be filtered/discarded by syslog. I will take up the second issue on the linux-audit mail list and hopefully have a patch Monday. It will take a new kernel to solve the above problems. As a work around, you can install the audit package and then set /etc/auditd.conf to have 2 logs with max log size of 1. This will allow 2 logs of 1 MB each so that you don't lose much disk space.
have to report that i just compiled a vanilla 2.6.12-git1 kernel and it works *OK* with audit-libs-0.9.8-1.
just tested the console output thing from comment #11 with 2.6.12-git1 and i only get it when the auditd service is not running. one thing i noticed is that i get an error message when restarting the service: sudo /sbin/service auditd restart Stopping auditd: [ OK ] Error receiving list (Success) Starting auditd: [ OK ] Error receiving list (Success) There was an error in line 5 of /etc/audit.rules but it seems to work ok.
(In response to comment #16) The error message should not be emitted if you are using 0.9.8. It is trying to clear file system watches and your kernel doesn't know what they are. That functionality will be available in a new kernel sometime soon. Thanks for the troubleshooting updates.
New version will be in rawhide next time its pushed out. In the mean time, you can build the srpm from http://people.redhat.com/sgrubb/audit if you wanted to get an early start on testing.
I tried 0.9.9 on 2.6.11 (vanilla) and the problem remains. Anything else I need to update?
problem was solved :-) after upgrading to kernel 1383_fc5 the thanks !
*** Bug 161014 has been marked as a duplicate of this bug. ***
(In responce to comment #19) I have put a 0.9.10 release at http://people.redhat.com/sgrubb/audit. What this does is change the message type and issue a retry. This way it follows the same fault tree that the original (failed) audit_send_message does. I located a 2.6.11 kernel and tried this release. 0.9.9 would let me in correctly, but xscreensaver would lock me out. With 0.9.10, xscreensaver is no longer a problem. Please report back whether it solves your problem. If it works for you, I will roll this one out to everyone. Thanks
I'm afraid the problem remains: [root@poseidon ~]# su su: incorrect password
0.9.10 fails for me too on kernel 2.6.12-rc3-love1
(In reply to comment #23) Could you attach a strace after removing and sensitive information? I need to see the failure mode to determine the appropriate fix. Thanks.
(In reply to comment #24) Could you attach a strace showing the failure using 0.9.10? I need to see the failure mode. Thanks.
Created attachment 115693 [details] Output of audit-libs 0.9.10-1 not working
(In reply to comment #27) Analysis of the strace shows that it found the same netlink packet the second time. The sequence number was still 1 even though the second sendto had a sequence number of 2. I have put another test srpm on my people site, audit-0.9.10-1.test.2.src.rpm. This one adds some code to recv the error packet before retrying. Please let me know if this solves the problem. Thanks.
Seems to work fine now. Great work! :)
Thanks for the feedback. I will put a "real" 0.9.10 into rawhide later.
A new audit daemon has been released to fix this problem. I am closing this bug report. Thanks to everyone providing data that solved all these issues.