[PATCH 2/3] dl-load: enforce soname uniqueness of loaded libraries

[Carlos O'Donell]

Nicolas,

Sorry to hear that. If you have any feedback you wish to share either
publicly or privately about the process, please don't hesitate to reach
out.

On 6/9/20 4:31 PM, Nicolas Viennot wrote:
> Hello Carlos,
> 
> I wanted to let you know that the copyright issue has not been solved between my employer and GNU.
> I have exhausted the amount of time I want to spend on this issue, so I am abandoning the patches.
> Thank you for the time you spent into this.
> 
> Nico.
> 
> -----Original Message-----
> From: Carlos O'Donell <codonell@redhat.com> 
> Sent: Saturday, February 1, 2020 12:49 AM
> To: Nicolas Viennot <Nicolas.Viennot@twosigma.com>; libc-alpha@sourceware.org
> Subject: Re: [PATCH 2/3] dl-load: enforce soname uniqueness of loaded libraries
> 
> On 1/6/20 10:44 AM, Nicolas Viennot wrote:
>> When loading a new library of name `libname`, the loader currently 
>> checks if any of the already loaded libraries have the soname `libname`.
>> If so, it returns the already loaded library of soname `libname`. If 
>> not, it checks for the corresponding file `libname` on disk and 
>> compares the device and inode number of already loaded libraries. If 
>> there is a match, it returns the already loaded library of the same inode number.
>> If not, it proceeds to load the library of path is `libname`.
>>
>> This patch adds the additional check of comparing the soname of the 
>> newly loaded library with the sonames of already loaded libraries.
>>
>> This new behavior enforces that no two loaded libaries have the same 
>> soname, bringing a sane property in the system.
>>
>> Note that this edge case can be encountered during a system upgrade, 
>> or when using certain configuration of file system mounts, where 
>> inodes cannot be relied upon.
> 
> Nicolas,
> 
> Thank you for working on this! This does look like an interesting patch and provides belt-and-suspenders and in general making the loader more robust against such odd failures is a good idea. We often see such things as crashes when systems are being live updated by rpm/dpkg etc.
> 
> Before we can accept any contributions we need a copyright assignment from you for glibc. This is handled by the FSF.
> 
> "FSF copyright Assignment"
> https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment
> 
> I suggest the futures assignment:
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
> 
> This would allow us to accept this patch and all subsequent patches you would want to submit. Given that you're submitting from a corporate email it may require you to check to see if your employer owns the copyright of your work, in which case they would need to sign a corporate assignment. The FSF will help you through this process, and we accept digital assignments now so the process is faster than ever before.
> 
> Please also have a look at the "Contribution Checklist":
> https://sourceware.org/glibc/wiki/Contribution%20checklist
> 
> Thank you again for your patches! I look forward to your contributions!
> 
> --
> Cheers,
> Carlos.
> 


-- 
Cheers,
Carlos.