[PATCH v5 04/22] elf: Suppress audit calls when a (new) namespace is empty (BZ #28062)

[Adhemerval Zanella]

On 11/11/2021 09:02, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 10/11/2021 11:15, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> diff --git a/elf/dl-load.c b/elf/dl-load.c
>>>> index 9f4fa9617d..72298776f6 100644
>>>> --- a/elf/dl-load.c
>>>> +++ b/elf/dl-load.c
>>>> @@ -1067,8 +1067,11 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd,
>>>>  	  && __glibc_unlikely (GLRO(dl_naudit) > 0))
>>>>  	{
>>>>  	  struct link_map *head = GL(dl_ns)[nsid]._ns_loaded;
>>>> -	  /* Do not call the functions for any auditing object.  */
>>>> -	  if (head->l_auditing == 0)
>>>> +	  /* Do not call the functions for any auditing object and also do not
>>>> +	     try to call auditing functions if the namespace is currently
>>>> +	     empty.  This happens when opening the first DSO in a new
>>>> +	     namespace.  */
>>>> +	  if (head != NULL && head->l_auditing == 0)
>>>>  	    {
>>>>  	      struct audit_ifaces *afct = GLRO(dl_audit);
>>>>  	      for (unsigned int cnt = 0; cnt < GLRO(dl_naudit); ++cnt)
>>>
>>> As far as I can tell, using GL(dl_ns)[nsid]._ns_loaded for la_activity
>>> is a completely arbitrary choice.  I think we should use
>>> &GL(dl_ns)[nsid] for secondary namespace instead, and keep
>>> GL(dl_ns)[LM_ID_BASE]._ns_loaded for backwards compatibility.
>>>
>>> This will allow us to generate an LA_ACT_ADD event for an empty
>>> namespace.
>>
>> I am not really following you here, '&GL(dl_ns)[nsid]' is just the container
>> here, we need to iterate over the 'link_maps' within it.
> 
> Hmm.  I had a peeked at the Solaris documentation, and it says that
> LA_ACT_ADD uses the head link map of the namespace as a cookie.
> 
> I really dislike that we produce a LA_ACT_DELETE without the
> corresponding LA_ACT_ADD due to this issue.
> 
> Can we use the link map allocated used _dl_new_object as the cookie if
> the namespace is empty?  This seems like the right thing to do here.
> The allocation happens just a few lines further down.

But afaiu the LA_ACT_ADD activity is to inform already loaded objects
that a new object is being processed.  Both man-pages and Solaris
documentation states 'objects are *being added*...', so I think passing
the cookie of the new allocated is not what the interface is suppose
to do.