From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Is zero a valid value for the pid member of the AUDIT_SIGNAL_INFO message? Date: Wed, 12 Mar 2014 12:07:36 -0400 Message-ID: <3374960.PoaQzalfXb@x2> References: <20140311221517.GA15334@madcap2.tricolour.ca> <2027464.v9FTcEdPSx@x2> <20140312153556.GC15334@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140312153556.GC15334@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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