From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] audit: log on the future execution of a path Date: Tue, 6 May 2014 11:10:11 -0400 Message-ID: <20140506111011.33f49a7b@ivy-bridge> References: <20140505171007.3d9d15f8@ivy-bridge> <1399388250.7627.15.camel@flatline.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1399388250.7627.15.camel@flatline.rdu.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: Richard Guy Briggs , linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, 06 May 2014 10:57:30 -0400 Eric Paris wrote: > On Mon, 2014-05-05 at 17:10 -0400, Steve Grubb wrote: > > On Mon, 5 May 2014 16:41:53 -0400 > > Richard Guy Briggs wrote: > > > > > Only problem is, it doesn't work. What assumptions am I making > > > that aren't valid about the approach in this kernel code? > > > > > > I also considered adding the path string pointer to the struct > > > audit_field. > > > > > > Any suggestions? > > > > What I was thinking about is that it should work a lot like a watch > > for > > We agree up to this point. > > > execution except when the watch triggers, it actually fills in a pid > > field for a syscall rule and loads it instead of emitting an event. > > And now we disagree. That's fine. It was only a suggestion. As long as the effect is the same, I don't care how its implemented. :-) -Steve