Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Thu, Sep 17, 2015 at 7:35 AM, Richard Guy Briggs wrote: > On 15/09/16, Paul Moore wrote: >> Otherwise, I think adding a result/success field to the >> AUDIT_CONFIG_CHANGE record makes sense as long as it doesn't break >> Steve's parsing code (I don't think it will, although it may simply >>

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/16, Paul Moore wrote: > On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs wrote: > > On 15/09/14, Paul Moore wrote: > >> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > >> > On 15/09/11, Paul Moore wrote: > >> > > Although I suppose if nothing else we could send a

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/16, Paul Moore wrote: > On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs wrote: > > On 15/09/14, Paul Moore wrote: > >> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > >> > On 15/09/11, Paul Moore wrote: > >> > > Although I suppose if nothing

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Thu, Sep 17, 2015 at 7:35 AM, Richard Guy Briggs wrote: > On 15/09/16, Paul Moore wrote: >> Otherwise, I think adding a result/success field to the >> AUDIT_CONFIG_CHANGE record makes sense as long as it doesn't break >> Steve's parsing code (I don't think it will, although it

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs wrote: > On 15/09/14, Paul Moore wrote: >> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: >> > On 15/09/11, Paul Moore wrote: >> > > Although I suppose if nothing else we could send a record indicating >> > > that another

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/14, Paul Moore wrote: > On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > > On 15/09/11, Paul Moore wrote: > > > Although I suppose if nothing else we could send a record indicating > > > that another auditd attempted to replace it ... if we can send it > > > great,

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/14, Paul Moore wrote: > On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > > On 15/09/11, Paul Moore wrote: > > > Although I suppose if nothing else we could send a record indicating > > > that another auditd attempted to replace it ... if we can send it > > > great,

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs wrote: > On 15/09/14, Paul Moore wrote: >> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: >> > On 15/09/11, Paul Moore wrote: >> > > Although I suppose if nothing else we could send a record indicating >> >

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > On 15/09/11, Paul Moore wrote: > > Although I suppose if nothing else we could send a record indicating > > that another auditd attempted to replace it ... if we can send it > > great, drop the new request and be glad we audited

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote: > On 15/09/11, Paul Moore wrote: > > Although I suppose if nothing else we could send a record indicating > > that another auditd attempted to replace it ... if we can send it > > great, drop the new request and be glad we audited

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/11, Paul Moore wrote: > On Fri, Sep 11, 2015 at 6:21 AM, Richard Guy Briggs wrote: > > On 15/09/09, Paul Moore wrote: > >> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > >> > On 15/09/07, Richard Guy Briggs wrote: > >> > > Nothing prevents a new auditd starting up

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/11, Paul Moore wrote: > On Fri, Sep 11, 2015 at 6:21 AM, Richard Guy Briggs wrote: > > On 15/09/09, Paul Moore wrote: > >> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > >> > On 15/09/07, Richard Guy Briggs wrote: > >> > > Nothing prevents a new

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Fri, Sep 11, 2015 at 6:21 AM, Richard Guy Briggs wrote: > On 15/09/09, Paul Moore wrote: >> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: >> > On 15/09/07, Richard Guy Briggs wrote: >> > > Nothing prevents a new auditd starting up and replacing a valid >> > > audit_pid

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/09, Paul Moore wrote: > On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > > On 15/09/07, Richard Guy Briggs wrote: > > > Nothing prevents a new auditd starting up and replacing a valid > > > audit_pid when an old auditd is still running, effectively starving out > > >

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Fri, Sep 11, 2015 at 6:21 AM, Richard Guy Briggs wrote: > On 15/09/09, Paul Moore wrote: >> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: >> > On 15/09/07, Richard Guy Briggs wrote: >> > > Nothing prevents a new auditd starting up and replacing a valid >>

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/09, Paul Moore wrote: > On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > > On 15/09/07, Richard Guy Briggs wrote: > > > Nothing prevents a new auditd starting up and replacing a valid > > > audit_pid when an old auditd is still running, effectively starving out > > >

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > On 15/09/07, Richard Guy Briggs wrote: > > Nothing prevents a new auditd starting up and replacing a valid > > audit_pid when an old auditd is still running, effectively starving out > > the old auditd since audit_pid no longer

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/08, Eric Paris wrote: > This is already going to be in the audit log, right? We're going to > send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet > it gets delivered to the old auditd. Actually, delivered by the new auditd is what I'm seeing... (Tested by running

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/08, Eric Paris wrote: > This is already going to be in the audit log, right? We're going to > send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet > it gets delivered to the old auditd. Actually, delivered by the new auditd is what I'm seeing... (Tested by running

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote: > On 15/09/07, Richard Guy Briggs wrote: > > Nothing prevents a new auditd starting up and replacing a valid > > audit_pid when an old auditd is still running, effectively starving out > > the old auditd since audit_pid no longer

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

This is already going to be in the audit log, right? We're going to send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet it gets delivered to the old auditd. But why is this a printk(KERN_WARN) ? On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote: > Nothing prevents a

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

This is already going to be in the audit log, right? We're going to send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet it gets delivered to the old auditd. But why is this a printk(KERN_WARN) ? On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote: > Nothing prevents a

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/07, Richard Guy Briggs wrote: > Nothing prevents a new auditd starting up and replacing a valid > audit_pid when an old auditd is still running, effectively starving out > the old auditd since audit_pid no longer points to the old valid auditd. > > There isn't an easy way to detect if an

[PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

Nothing prevents a new auditd starting up and replacing a valid audit_pid when an old auditd is still running, effectively starving out the old auditd since audit_pid no longer points to the old valid auditd. There isn't an easy way to detect if an old auditd is still running on the existing

Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

On 15/09/07, Richard Guy Briggs wrote: > Nothing prevents a new auditd starting up and replacing a valid > audit_pid when an old auditd is still running, effectively starving out > the old auditd since audit_pid no longer points to the old valid auditd. > > There isn't an easy way to detect if an

[PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd

Nothing prevents a new auditd starting up and replacing a valid audit_pid when an old auditd is still running, effectively starving out the old auditd since audit_pid no longer points to the old valid auditd. There isn't an easy way to detect if an old auditd is still running on the existing