Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160929 - unable to login after upgrade to audit-libs-0.9.7-1
Summary: unable to login after upgrade to audit-libs-0.9.7-1
Alias: None
Product: Fedora
Classification: Fedora
Component: audit
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Grubb
QA Contact:
: 161014 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-18 19:56 UTC by Tomas Lastovicka
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 0.9.15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-14 13:08:34 UTC

Attachments (Terms of Use)
output of working audit-libs-0.8.2-1 (deleted)
2005-06-19 01:09 UTC, Lars G
no flags Details
output of not working audit-libs-0.9.8-1 (deleted)
2005-06-19 01:11 UTC, Lars G
no flags Details
Output of audit-libs 0.9.10-1 not working (deleted)
2005-06-20 15:10 UTC, Naadir Jeewa
no flags Details

Description Tomas Lastovicka 2005-06-18 19:56:13 UTC
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): 
How reproducible: 
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

Comment 1 Steve Grubb 2005-06-18 22:30:49 UTC
What version of pam are you using? Do you make your own kernel without
CONFIG_AUDITSYSCALL? Do you have /proc/self/loginuid?

Comment 2 Steve Grubb 2005-06-18 22:32:08 UTC
Also, could you get a strace of su? I'm interested in the return code from
sendto syscall. Thanks.

Comment 3 Tomas Lastovicka 2005-06-18 22:58:50 UTC
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 , lines 
containing my /etc/group and /etc/passwd are removed 

Comment 4 Steve Grubb 2005-06-18 23:43:57 UTC
Thanks. Just to make sure, is that strace one from a failed session? 

Comment 5 Lars G 2005-06-19 01:09:39 UTC
Created attachment 115658 [details]
output of working audit-libs-0.8.2-1

Comment 6 Lars G 2005-06-19 01:11:02 UTC
Created attachment 115659 [details]
output of not working audit-libs-0.9.8-1

Comment 7 Lars G 2005-06-19 01:13:31 UTC
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.

Comment 8 Tomas Lastovicka 2005-06-19 09:29:48 UTC
(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.. 

Comment 9 Steve Grubb 2005-06-19 16:12:44 UTC
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.

Comment 10 Steve Grubb 2005-06-19 16:18:33 UTC
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.

Comment 11 Tomas Lastovicka 2005-06-19 16:44:29 UTC
(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 
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 :) 

Comment 12 Steve Grubb 2005-06-19 17:03:16 UTC
(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.

Comment 13 Tomas Lastovicka 2005-06-19 17:27:34 UTC
(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?  

Comment 14 Steve Grubb 2005-06-19 17:46:37 UTC
(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.

Comment 15 Lars G 2005-06-19 17:57:20 UTC
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.

Comment 16 Lars G 2005-06-19 18:07:20 UTC
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.

Comment 17 Steve Grubb 2005-06-19 18:17:00 UTC
(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.

Comment 18 Steve Grubb 2005-06-19 20:16:01 UTC
New version will be in rawhide next time its pushed out. In the mean time, you
can build the srpm from  if you wanted to
get an early start on testing.

Comment 19 Pierre Ossman 2005-06-20 09:30:25 UTC
I tried 0.9.9 on 2.6.11 (vanilla) and the problem remains. Anything else I need
to update?

Comment 20 Nadav Kavalerchik 2005-06-20 12:02:43 UTC
problem was solved :-)   
 after upgrading to kernel 1383_fc5 the    
thanks !   

Comment 21 Tomas Mraz 2005-06-20 12:12:19 UTC
*** Bug 161014 has been marked as a duplicate of this bug. ***

Comment 22 Steve Grubb 2005-06-20 13:24:40 UTC
(In responce to comment #19)
I have put a 0.9.10 release at 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

Comment 23 Pierre Ossman 2005-06-20 13:51:34 UTC
I'm afraid the problem remains:

[root@poseidon ~]# su
su: incorrect password

Comment 24 Naadir Jeewa 2005-06-20 13:56:31 UTC
0.9.10 fails for me too on kernel 2.6.12-rc3-love1

Comment 25 Steve Grubb 2005-06-20 14:23:35 UTC
(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.

Comment 26 Steve Grubb 2005-06-20 14:27:39 UTC
(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.

Comment 27 Naadir Jeewa 2005-06-20 15:10:18 UTC
Created attachment 115693 [details]
Output of audit-libs 0.9.10-1 not working

Comment 28 Steve Grubb 2005-06-20 18:54:21 UTC
(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.

Comment 29 Pierre Ossman 2005-06-20 19:20:54 UTC
Seems to work fine now. Great work! :)

Comment 30 Steve Grubb 2005-06-20 21:03:54 UTC
Thanks for the feedback. I will put a "real" 0.9.10 into rawhide later.

Comment 31 Steve Grubb 2005-07-14 13:08:34 UTC
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.

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