From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH 1/2] add SIGNAL syscall class Date: Wed, 14 Feb 2007 15:32:02 -0500 Message-ID: <200702141532.02447.sgrubb@redhat.com> References: <20070214182431.GA17337@fc.hp.com> <200702141404.07353.sgrubb@redhat.com> <20070214201205.GA18196@fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070214201205.GA18196@fc.hp.com> 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: Amy Griffis Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday 14 February 2007 15:12:05 Amy Griffis wrote: > Steve Grubb wrote: [Wed Feb 14 2007, 02:04:07PM EST] > > > On Wednesday 14 February 2007 13:24:31 Amy Griffis wrote: > > > Add a syscall class for sending signals. > > > > The intent of the syscall classes had been to make an update independent > > way of being able to specify audit rules for filesystem auditing where > > new syscalls could be added. > > Yeah, I know I used it in a different way from the original purpose. So, how does this work from a user perspective? Do you need to patch auditctl? > But I think this is still a valid use... When we are adding or > removing a rule, we need a way to determine if the rule specified one > of the syscalls for sending signals. Could you show a sample use? (Just so I understand what its doing.) > Makes sense. Do you think we're in danger of running out of slots for > syscall classes? I think we should be fairly conservative. I hadn't quite got to the point of saying we needed close and delete since I am still thinking about the requirements. Thanks, -Steve