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

[Richard Guy Briggs]

On 14/03/12, Steve Grubb wrote:
> 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.

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.

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

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs at 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