PAL, Really appreciate you looking into this. With the logcollector no longer segfaulting, could you check whether the linux_auditd logs are processed and rules fired correctly?
On Wednesday, September 19, 2012 2:40:03 AM UTC-7, PAL wrote: > > I tried to install OSSEC 2.7 in my environment. > Unfortunately, logcollector have a serious problem. > I defined config like: > > <localfile> > >> >> <log_format >> timeout="2">linux_auditd</log_format> >> >> >> >> <location>/var/log/audit/audit.log</location> >> >> >> </localfile> >> > > I got logcollector segfault in short time. > I made some exploring. File was successfully accessed until start but lost > access in few minutes (looks like because audit.log is updated frequently) > , and after that logcollector segfault'ed. > > Ok, lets to debug. As I found, when file not available, it's marked by set > logff[i].ign to 999 and logff[i].fp to null. > BUT! In next cycle logcollector will try to interpret this file as > "command" type! This will incorrectly set size and position and when > function "read" will call, we got segfault > > For example, debug session: > > gdb ./client-logcollector -f > [New process 11610] > [New process 11611] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to process 11611] > 0x00002aaaaad2bb1c in fgetpos64@@GLIBC_2.2.5 () from /lib64/libc.so.6 > (gdb) bt > #0 0x00002aaaaad2bb1c in fgetpos64@@GLIBC_2.2.5 () from /lib64/libc.so.6 > #1 0x0000000000405d6a in read_linux_audit (pos=3, drop_it=0) at > read_linux_audit.c:157 > #2 0x00000000004033f0 in LogCollectorStart () at logcollector.c:349 > #3 0x0000000000404992 in main (argc=1, argv=0x7fffffffc658) at main.c:184 > (gdb) > > > The same happened (but not in allway, strange, hm) when I add to config > nonexisted file > > I make a patch (in attachment), which allow to avoid this problem > After a day of testing logcollector work fine > >
