[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-154-g826ee30

[Steve Langasek]

On Thu, Jul 02, 2009 at 10:22:05AM -0400, simo wrote:

> >  > If, through dependencies, both get loaded in the same process space, and
> >  > both use the same symbol names, you are doomed.

> > err .. the loader is supposed to sort that out and use one. Metze has
> > explained that it can screw up (though I don't fully understand how),
> > and has proposed a patch that catches it if it happens. I certainly
> > don't mind putting in that patch as a extra precaution.

> This is how it can happen:
> App A links talloc.so.1 and libsmbclient
> New libsmbclient links talloc.so.2

Is this anything other than a hypothetical?

In Debian, for instance, I find only three packages which depend on
libtalloc: ldb, samba, and tevent.  None of which use libsmbclient.

It may be worse on systems whose runtime linker doesn't do sensible
recursion (e.g., Solaris), but I'm not sure if that's what you're speaking
to here?  Certainly not wrt glibc...

> The only libraries I can see with 2 sonames in my Fedora are KDE
> libraries, 10 or so, their internal symbols are all auto-generated, and
> they are never loaded together in the same app because they are internal
> KDE libs nobody directly links them in so there is probably little to no
> risk.
> I see no other library distributed in 2 soname versions in my F-10.

Hmm, you guys have managed to only have one version of BDB in the distro at
a time?  I'm impressed. :)

> > In fact, the whole darn point of having so numbers is so you _can_
> > have multiple installed at once, and so old apps that linked against
> > the old version will still work. 

> No, the soname bumps is meant to make your app fail to even start with a
> linker error if you don't have the right version.
> The fact you can install 2 in parallel is just a consequence, sometimes
> useful, sometimes dangerous. In the talloc case I think it is just
> dangerous.

I don't think there's anything special about talloc in this regard.  Any
library that has other shared libraries as reverse-dependencies suffers from
this possible problem, which is why I routinely recommend that all such
libraries should use symbol versioning.

It should be noted that this only solves the problem for glibc-based
systems, not with systems using less clever runtime linkers.  I don't think
that's a problem if users of other systems have to do other manual work to
ensure their system is in a consistent state, but some people do.

On Fri, Jul 03, 2009 at 10:45:14AM +1000, Andrew Bartlett wrote:
> > At load time glibc loads talloc.so.1 into app A, then it loads
> > libsmbclient, which loads talloc.so.2
> > Now, most symbols are resolved by talloc.so.1 so glibc does not replace
> > them. A few new symbols though are not available so it loads them.
> > Simple and devastating.

> Isn't this what symbol versions are meant to prevent?

Yep.

> > No, the soname bumps is meant to make your app fail to even start with a
> > linker error if you don't have the right version.
> > The fact you can install 2 in parallel is just a consequence, sometimes
> > useful, sometimes dangerous. In the talloc case I think it is just
> > dangerous.

> Only dangerous without symbol versions, right?

Indeed.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org