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

On Tuesday, March 11, 2014 11:32:01 PM Richard Guy Briggs wrote: > On 14/03/11, Eric Paris wrote: > > On Tue, 2014-03-11 at 18:15 -0400, Richard Guy Briggs wrote: > > > Is zero a valid value for the pid member of the AUDIT_SIGNAL_INFO > > > message? > > > > No... > > > > Given that userspace requests AUDIT_SIGNAL_INFO after it gets a signal, > > and that audit_sig_{uid,pid,...} get filled in when some task sent > > auditd that signal, the idea that the pid would be 0 doesn't make > > sense... (unless auditd requests AUDIT_SIGNAL_INFO without getting a > > signal, but that's just dumb) > > The reason I ask is that it is initialized to -1, which I assume is no > more valid than zero in your interpretation above. 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.

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

-Steve