On Tuesday, December 22, 2015 04:03:06 AM 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. > > If no message to auditd has been attempted since auditd died unnaturally > or got killed, audit_pid will still indicate it is alive. There isn't > an easy way to detect if an old auditd is still running on the existing > audit_pid other than attempting to send a message to see if it fails. > An -ECONNREFUSED almost certainly means it disappeared and can be > replaced. Other errors are not so straightforward and may indicate > transient problems that will resolve themselves and the old auditd will > recover. Yet others will likely need manual intervention for which a > new auditd will not solve the problem. > > Send a new message type (AUDIT_REPLACE) to the old auditd containing a > u32 with the PID of the new auditd. If the audit replace message > succeeds (or doesn't fail with certainty), fail to register the new > auditd and return an error (-EEXIST). > > This is expected to make the patch preventing an old auditd orphaning a > new auditd redundant. > > V3: Switch audit message type from 1000 to 1300 block. > > Signed-off-by: Richard Guy Briggs <r...@redhat.com> > --- > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 16 +++++++++++++++- > 2 files changed, 16 insertions(+), 1 deletions(-) > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > index 843540c..d820aa9 100644 > --- a/include/uapi/linux/audit.h > +++ b/include/uapi/linux/audit.h > @@ -110,6 +110,7 @@ > #define AUDIT_SECCOMP 1326 /* Secure Computing event */ > #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */ > #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes */ > +#define AUDIT_REPLACE 1329 /* Replace auditd if this > packet...
Steve, are you okay with this record number? -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
