Re: [Gábor Gombás] Bug#564566: libkadm5clnt7: SONAME conflict with Heimdal

[Jeffrey Hutzelman]

--On Monday, January 11, 2010 03:35:57 PM -0500 Sam Hartman 
<hartmans at MIT.EDU> wrote:

>>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:
>
>     Tom> Luke Howard <lukeh at padl.com> writes:
>     >> On 11/01/2010, at 5:58 PM, Nicolas Williams wrote:
>     >>
>     >>> Provided the libraries have different install locations,
>     >>> programs properly use rpath, and that the Heimdal and MIT
>     >>> libraries need never be loaded in the same process at once, then
>     >>> SONAME conflicts are not a problem.
>     >>>
>     >>> However, with plug-in interfaces galore it's very likely that
>     >>> both will be loaded in the same process at some point.
>     >>
>     >> Right, but RTLD_LOCAL should be used (HDBBridge uses this to have
>     >> Heimdal and MIT libraries in the KDC).
>
> Note that Debian uses the same install location, does not use rpath, and
> may run into situations where Heimdal and MIT libraries are loaded in
> the same process.  It's not all that likely that libkadm5clnt will be
> one of the libraries that gets loaded in the same process, although I
> suspect is common that Heimdal and MIt libkrb5 are loaded in the same
> process on Debian systems.
>
>     Tom> How well do various platforms cope with maintaining isolation
>     Tom> between shared libraries having the same SONAME but different
>     Tom> contents?
>
> I'm not sure about this situation; I suspect that RTLD_LOCAL would get
> reasonable behavior.  However exactly because I'm using the same
> installation location and no rpath (both by policy), that approach
> doesn't matter to me.

RTLD_LOCAL itself is not enough, you also need something (RTLD_GROUP or 
RTLD_DEEP_BIND) to prevent references in a newly-loaded group from being 
satisfied by symbols defined in the main program (or its dependencies).


> The GNU C library's elf interpreter seems to care a lot more about
> symbol version in terms of resolving conflicts than it does soname.

sonames are used only in locating libraries; they are not part of 
individual symbol references, directly or indirectly.  In satisfying symbol 
references, all ld.so has to go on is the symbol name (including version) 
and the set of objects to search in.  If you can ensure that a particular 
version of a library is the only one visible during the search, then you'll 
get the right symbol, regardless of whether there is another library loaded 
with that soname.  If the _wrong_ library is visible during the search, 
you'll get the wrong symbol, even if the sonames don't match.

Of course, if the symbol versions also don't match, symbol resolution will 
just fail and things will not work at all.  Symbol versioning, especially 
of the rich variety provided by glibc, can be used here to prevent the 
wrong thing from happening, but it can't make the right thing happen.

I'm with Russ; clearly, the best answer is to coordinate with Heimdal and 
agree to partition the soname version space in a reasonable way.


-- Jeff