Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:19, Richard Guy Briggs wrote: > On 2018-02-15 18:07, Steve Grubb wrote: > > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > > records to be associated with the init_module and

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:19, Richard Guy Briggs wrote: > On 2018-02-15 18:07, Steve Grubb wrote: > > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote: > > > Tracefs or debugfs were causing hundreds to thousands of null PATH > > > records to be associated with the init_module and

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST 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

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST 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

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST 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

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Richard Guy Briggs
On 2018-02-15 18:07, Steve Grubb wrote: > On Monday, February 12, 2018 12:02:21 AM EST 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

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Steve Grubb
On Monday, February 12, 2018 12:02:21 AM EST 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 ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-15 Thread Steve Grubb
On Monday, February 12, 2018 12:02:21 AM EST 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: >

[PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-11 Thread Richard Guy Briggs
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 ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

2018-02-11 Thread Richard Guy Briggs
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