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

Nicolas Viennot Nicolas.Viennot@twosigma.com
Tue Jun 9 20:31:15 GMT 2020


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.



More information about the Libc-alpha mailing list