On Tue, 9 Apr 2019 11:57:28 -0400
Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2019-04-09 17:37, Steve Grubb wrote:
> On Tue, 9 Apr 2019 10:02:59 -0400
> Richard Guy Briggs <rgb(a)redhat.com> wrote:
>
> > On 2019-04-09 08:01, Steve Grubb wrote:
> > > On Mon, 8 Apr 2019 23:52:29 -0400 Richard Guy Briggs
> > > <rgb(a)redhat.com> wrote:
> > > > When a process signals the audit daemon (shutdown, rotate,
> > > > resume, reconfig) but syscall auditing is not enabled, we
> > > > still want to know the identity of the process sending the
> > > > signal to the audit daemon.
> > >
> > > Why? If syscall auditing is disabled, then there is no
> > > requirement to provide anything. What is the real problem that
> > > you are seeing?
> >
> > Shutdown messages with -1 in them rather than the real values.
>
> OK. We can fix that by patching auditd to see if auditing is enabled
> before requesting signal info. If auditing is disabled, the proper
> action is for the kernel to ignore any audit userspace messages
> except the configuration commands.
If auditing is disabled in the kernel, none of this is trackable. It
is for those as yet unsupported arches that can run audit enabled but
without auditsyscall support.
Ok. I suppose this is useful for this use case. No further objections.
-Steve