All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Simon Jones <sjones@tusc.com.au>
Subject: Re: RHEL-AS-4.4 and auditd-1.0.14
Date: Sat, 10 Feb 2007 09:27:43 -0500	[thread overview]
Message-ID: <200702100927.43533.sgrubb@redhat.com> (raw)
In-Reply-To: <8585B1BA-20C5-4733-B12E-A5B85ACE62F5@tusc.com.au>

On Thursday 08 February 2007 23:12, Simon Jones wrote:
> I've had a quick look over the archives and couldn't find anything,  
> so if this has already been fixed, please be kind...

No one has reported any problem of this kind.

> I went from using the standard CAPP.rules example file to the  
> following audit.rules file:

This reduces what the kernel is doing. Does this also reduce the number of 
events hitting your audit logs?


> -D
> -w /etc -p w -k ETC

This only records writes to the /etc directory and not the files in the /etc 
directory.

> -w /etc/sysconfig -p w -k SYSCONFIG
> -w /caer/e/cnf -p w -k DMS_CNF
> -w /caer/g/cnf -p w -k GAS_CNF
> -w /bin/su -p x -k SBIN
>
> A glance at cat /proc/slabinfo shows that there may be a memory leak:
> After two minutes:
> size-32            13447  13447     32  119    1 : tunables  120    
> 60    8 : slabdata    113    113      0
> After several hours:
> size-32           18598891 18599105     32  119    1 : tunables  
> 120   60    8 : slabdata 156295 156295      0

I wonder if you still see the leak if you load the rules but do not start the 
audit daemon? We need to see if its a kernel memory leak or user space. I've 
run valgrind against auditd and do not know of any leaks.

>
> Whereas on a server not running the auditd daemon a cat /proc/
> slabinfo gives:
> After two minutes:
> size-32             3556   3808     32  119    1 : tunables  120    
> 60    8 : slabdata     32     32      0
> After several hours:
> size-32             3601   3808     32  119    1 : tunables  120    
> 60    8 : slabdata     32     32      0

But do you still have the CAPP rules loaded?

> I found this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?
> id=193542#c15 bug that seems to have a similar problem...

similar but different.

> If so has it been fixed in 1.0.15?

No one's reported such an issue...so no one's worked on it. The first step is 
determining if the problem is kernel or user space. Please load the CAPP 
rules without starting the audit daemon and see what that shows.

Thanks,
-Steve

  reply	other threads:[~2007-02-10 14:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-09  4:12 RHEL-AS-4.4 and auditd-1.0.14 Simon Jones
2007-02-10 14:27 ` Steve Grubb [this message]
2007-02-12 22:54   ` Simon Jones
2007-02-13  2:33     ` Steve Grubb
2007-02-13 23:07       ` Simon Jones
2007-02-13 23:20         ` Simon Jones
2007-02-14 17:42           ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200702100927.43533.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=sjones@tusc.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.