Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-08-11 02:36, Richard Guy Briggs wrote: > On 2017-06-28 15:03, Paul Moore wrote: > > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > > On 2017-05-30 17:21, Paul Moore wrote: > > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs > > >>

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-08-11 02:36, Richard Guy Briggs wrote: > On 2017-06-28 15:03, Paul Moore wrote: > > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > > On 2017-05-30 17:21, Paul Moore wrote: > > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs > > >> wrote: > > > > ... > > > > >> >

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c b/kernel/audit.c > >> > index

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-29 19:58, Steven Rostedt wrote: > On Thu, 29 Jun 2017 17:21:22 -0400 > Richard Guy Briggs wrote: > > > > Looking at this again today, why would we want to clear name->dentry > > > in audit_copy_inode() if it is already set? Does that ever happen? > > > I'm not sure

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-29 19:58, Steven Rostedt wrote: > On Thu, 29 Jun 2017 17:21:22 -0400 > Richard Guy Briggs wrote: > > > > Looking at this again today, why would we want to clear name->dentry > > > in audit_copy_inode() if it is already set? Does that ever happen? > > > I'm not sure it does ... > >

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Thu, 29 Jun 2017 17:21:22 -0400 Richard Guy Briggs wrote: > > Looking at this again today, why would we want to clear name->dentry > > in audit_copy_inode() if it is already set? Does that ever happen? > > I'm not sure it does ... > > It has been nearly 3 months since I

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Thu, 29 Jun 2017 17:21:22 -0400 Richard Guy Briggs wrote: > > Looking at this again today, why would we want to clear name->dentry > > in audit_copy_inode() if it is already set? Does that ever happen? > > I'm not sure it does ... > > It has been nearly 3 months since I coded that, so

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-06-28 15:03, Paul Moore wrote: > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > On 2017-05-30 17:21, Paul Moore wrote: > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > ... > > >> > diff --git a/kernel/audit.c b/kernel/audit.c > >> > index

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > On 2017-05-30 17:21, Paul Moore wrote: >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: ... >> > diff --git a/kernel/audit.c b/kernel/audit.c >> > index 25dd70a..7d83c5a 100644 >> > ---

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > On 2017-05-30 17:21, Paul Moore wrote: >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: ... >> > diff --git a/kernel/audit.c b/kernel/audit.c >> > index 25dd70a..7d83c5a 100644 >> > --- a/kernel/audit.c >> > +++

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-05-30 17:21, Paul Moore wrote: > On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-05-30 17:21, Paul Moore wrote: > On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when the following rule

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: >

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: > -a

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-04-04 17:19, Paul Moore wrote: > On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-04-04 17:19, Paul Moore wrote: > On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > records to be associated with the init_module and finit_module SYSCALL > > records on a few modules when the following rule

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: >

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: > -a

[PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

Tracefs or debugfs were causing hundreds to thousands of null PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load This happens

[PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

Tracefs or debugfs were causing hundreds to thousands of null PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load This happens