Red Hat Bugzilla – Bug 160929
unable to login after upgrade to audit-libs-0.9.7-1
Last modified: 2007-11-30 17:11:08 EST
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,
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):
Steps to Reproduce:
1. upgrade to audit-libs-0.9.7-1
2. try lo log in
unable to login, message in /var/log/secure
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
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
audit(1119198450.962:2): user pid=2242 uid=0 auid=4294967295 msg='PAM
authentication: user=root exe="/bin/login" (hostname=?, addr=?, ter
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
> old kernel work. I just wanted to confirm this was the problem and not SE
> 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
> I don't think it should be coming out on the terminal, though. I will follow
> 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
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
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
problem was solved :-)
after upgrading to kernel 1383_fc5 the
*** 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.