From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Filesystem access statistics Date: Thu, 13 Apr 2006 09:50:51 -0400 Message-ID: <200604130950.51387.sgrubb@redhat.com> References: <20060412152325.GA1399@plain.rackshack.net> <200604121226.29081.sgrubb@redhat.com> <20060412201233.GB1399@plain.rackshack.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060412201233.GB1399@plain.rackshack.net> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday 12 April 2006 16:12, Rudi Chiarito wrote: > On Wed, Apr 12, 2006 at 12:26:29PM -0400, Steve Grubb wrote: > > I would think that you could write a program to do this via the audit > > dispatcher interface. In auditd.conf, > > dispatcher = /usr/bin/your-program > > log_format = nolog > > Will that preempt any other audit users that might be looking for > events downstream? Yes it will, but the audit event dispatcher is not ready yet. So, if you want something today, you can just take over the interface. Then re-write it as a plugin later when the event dispatcher is finished. > > if (hdr.type == AUDIT_PATH) { > > libaudit.h from audit-libs-devel 1.1.5-1 only has AUDIT_FS_INODE. libaudit.h includes linux/audit.h which defines the AUDIT_PATH message type. > Is this new in 1.2 or a typo? Its been around for at least a year. > I saw mention of a new filesystem API in the audit RPM changelog. Is that > part of it? No. > > You can then set the audit rules for whatever you want to measure, if all > > you want to measure is the opens, > > That's a very good question by itself. Anything that peeks into a > directory should do, I guess. That would mean not just opens, but also > directory traversals, unlink calls, etc. Are there aliases of any kind? No. > The kernel just gained a bunch of new *at() syscalls. If I had written > this a month or two ago, I would have most likely missed them. Is there > a way to look for present and future syscalls dealing with files/inodes? Not at the moment. -Steve