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

[Steve Grubb]

On Wednesday, March 12, 2014 11:35:56 AM Richard Guy Briggs wrote:
> > pid=-1 has a special meaning for signals. But in terms of seeing it in a 
> > sigaction handler for siginfo, not possible. So its a good init value. If
> > you  look at sigaction(2), there is a si_code that indicates why the
> > signal was sent. One of them is SI_KERNEL. So, its possible that the
> > kernel decides to send a signal on certain occasions.
> 
> That message is only sent on request from userspace, so I suppose
> userspace could request that information at any time, but the only time
> it would be meaningful is after that userspace process has received a
> signal.

Sure.

> > > 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.

-Steve