From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Adding multiple watch rules on same path Date: Tue, 22 Aug 2006 11:51:14 -0400 Message-ID: <200608221151.14150.sgrubb@redhat.com> References: <44EB239D.4040709@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <44EB239D.4040709@us.ibm.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: Loulwa Salem Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday 22 August 2006 11:32, Loulwa Salem wrote: > As I was running some of our watch tests, I noticed the following: > You can add multiple watches on the same path if you specify different > filter key values. That doesn't make sense to me, so I wanted to check if > that is an intended behavior? I have programmed anything to allow or disallow this behavior. I'm sure there are many many combinations of things that do not make sense together like any field other than -F messagetype when exclude filter is picked. But I have not thought up all combinations of what should and should not be allowed. The logic for that might make auditctl more complex than it need be. On the otherhand, suppose you wrote a system that dynamically alters the audit rules. You could use the keyfield to identify those rules so that you do not have to think about baseline rules the admin may have in place. IOW, you can issue another rule to watch /etc/shadow for writes without checking to see if it already exists. Also, you can delete the rule without worry that you are deleting something the admin wants there as baseline. So, I can sort of see a use for it. > Is this is how auditctl will remain to function, because we need to make > changes to our functions accordingly I'm undecided about whether to keep the behavior or not. I don't see much harm in it and it might turn out to be useful. -Steve