Re: Is zero a valid value for the pid member of the AUDIT_SIGNAL_INFO message?

[Richard Guy Briggs <rgb@redhat.com>]

On 14/03/12, Steve Grubb wrote:
> On Wednesday, March 12, 2014 11:35:56 AM Richard Guy Briggs wrote:
> > > > I looked at converting audit_sig_pid from pid_t to struct pid *, but
> > > > then get_pid() would also be needed to protect that reference.  A
> > > > put_pid() would need to be done once it is no longer needed, which could
> > > > be immediately after it is read in the AUDIT_SIGNAL_INFO message
> > > > preparation, assuming it would never need to be read again.  If this
> > > > isn't the case, put_pid() could be called when audit_pid is nulled, but
> > > > if that message never comes, that struct pid is stuck with a stale
> > > > refcount.  (That isn't an issue if it is init or systemd, but it is
> > > > still wrong.)
> > > >
> > > > This looks more and more like overkill and should probably leave
> > > > audit_sig_pid as pid_t.
> > >
> > > The code has been working good for a long time. I am wondering if the
> > > original  intent was to make it general in case we decided to add more
> > > signals that we are interested in.
> > 
> > Such as HUP to reread config or other possibilities?
> 
> I think we started with sigterm. Then we needed sighup. Then needed usr1 & 
> usr2. Somewhere along the way I think it was just decided to make it open 
> ended in case more were needed later.

Currently, TERM, HUP, USR1 and USR2 but no others cause audit_sig_pid to be set.

Other signals only cause the target task to be added to the target list.

So what is the use case to send any other signal, causing the target to
only be added to the context target list?

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545