On Thu, 03 Nov 2011 at 23:37:37 +0100, Dominic Fandrey wrote:
> On 03/11/2011 17:58, Simon McVittie wrote:
> > This change isn't right. libcurl.so is the development symlink for libcurl
> > [...] Non-developer systems
> > should only have the symlink named after the SONAME (libcurl.so.4 or
> > libcurl.so.3), and the real file that the symlinks point to
> > (libcurl.so.4.2.0
> > or whatever).
>
> That's rather strange. On FreeBSD the current version is libcurl.so.6.
> And the .so file always links to the currently installed version of the
> library. I always thought that was the normal way of things to be.
FreeBSD libtool library versioning isn't quite the same as on Linux,
so it's not necessarily surprising that the current libcurl ends up with a
different SONAME for you (libtool treats the platforms differently) - it's
probably the same libcurl version under a different name. I believe the
general structure is the same, though.
On Linux, at least, you typically have:
libfoo.so.0.1.2 - real file, nothing should be using this name directly
libfoo.so.0 - the name that gets written into binaries by the linker,
and hence the name that the binary needs to find on startup;
symlink to the real file
libfoo.so - used by the compiler/linker, typically "gcc -lfoo", to find
the current version of foo; symlink to the real file
The purpose of this is that you can have libfoo.so.0 and libfoo.so.1
installed at the same time, to support a new executable that was compiled
against libfoo.so.1 and an older one compiled against libfoo.so.2 (but you
have to choose one or the other to compile new executables against, because
when you compile you just say "-lfoo" - the libfoo.so symlink points to that).
Think of libfoo.so.0 as "libfoo.so, compatibility level 0".
> That the interface was changed, doesn't necessarily mean that you are
> affected. If you were the game wouldn't compile in the first place.
The version of libfoo you compiled against isn't necessarily the version
you have at runtime; you can upgrade the library and not recompile the
executable. If the upgraded library is compatible, it will overwrite the
old one (libfoo.so.0 previously pointed to libfoo.so.0.1.2, now it points
to libfoo.so.0.2.3) and the executable will just use the upgraded version.
If it isn't compatible, libfoo.so.0 will stay as it was, and the new version
will be installed in parallel as libfoo.so.1 - the executable isn't using the
upgraded version, and that's right, because by increasing the SONAME, the
author of libfoo was saying "this version is compatibility level 1, and
isn't compatible with compatibility level 0 any more".
> I can see how an interface change could cause a crash, but I don't see
> how it can cause security issues.
For instance, a typical ABI break that would result in a new SONAME is a
struct becoming larger (maybe struct foo in libfoo.so.0 is 20 bytes and
struct foo in libfoo.so.1 is 32 bytes). If you write a new struct with
partially attacker-controlled contents into a location only large enough
for the old struct, that's a stack or heap overflow, which could well be
exploitable (e.g. if it can overwrite the return address or a function
pointer).
> I see it doesn't work that way. Hard coding library versions doesn't sound
> like a very good idea to me, too, though.
If you set USE_CURL_DLOPEN=0 the compiler will automatically pick up the
SONAME you compiled against, write it into the binary, and it'll work like
every other library (e.g. libjpeg, commonly seen with SONAME libjpeg.so.6
or libjpeg.so.8). I'd recommend that for distribution packages - it's almost
certainly how every other executable in your distribution works.
S
_______________________________________________
ioquake3 mailing list
ioquake3@lists.ioquake.org
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.
