2

I've CentOS 6.0 server with glibc-2.12-1.7.el6.x86_64 running many open source services and some of my own C programs.

To fix ghost vulnerability, I need to update it to glibc-2.12-1.149.el6_6.5.

Since the version difference seems large.

I was wondering whether I need to recompile my C/C++ apps or even some of the open source services ?
How do I even test them bcos testing everything is next to impossible ?

I've read that some people had to revert the update bcos they faced segfaults in their apps.

3

Linux applications almost always use dynamic linking to the C library, meaning it is not compiled into them -- it is linked at runtime. This means if you have upgraded the C library, you should not have to do anything else.

However, while it would be very unusual, it is not impossible for things to be built with a statically linked glibc. The best thing to do is just look at the documentation for the application in question. If this is the practice, it is almost certainly explicit.

You can check executables with file. It should say "dynamically linked" in the output. I think it is still possible for such a binary to then incorporate a static glibc -- but this would be incredibly obtuse. The way to double check would be:

ldd whatever | grep libc.so

Where whatever is the binary you want to check. You should get some output. If not, leave a comment here so I can eat my hat because I don't believe anyone would create such a thing.

If you do find an actual static binary, this does not mean it necessarily used glibc. You'd have to confirm that by consulting the source tree, documentation, or developers.

I've read that some people had to revert the update bcos they faced segfaults in their apps.

I've seen that second and third hand too. I haven't actually seen a concrete description of such a case though. I think it is very unlikely, to be honest.

  • Since the major version is same i.e 2.12.1, there will be no api breaks right ? The function interfaces will remain same? – amolkul Feb 16 '15 at 6:38
  • The glibc API is 100% backward compatible anyway. The ABI is sometimes a little less than that but pretty close. I would not worry about it for a minor bug patch. – goldilocks Feb 16 '15 at 12:29
0

First off, Red Hat Enterprise Linux keeps the base of their packages as long as humanly possible, and keep strict binary compatibility. If you analyze the versions of glibc, 2.12-1.7.el6.x86_64 vs 2.12-1.149.el6_6.5 (I presume a .x86_64 is missing here), you have it is upstream version 2.12 for both, local (RHEL) version is 1.7 against 1.149 (i.e., some 142 sets of patches). One is for el6 (i.e., RHEL 6) the other for el6_6.5 (i.e., the 5th round of updates bundled into a "new release" of RHEL 6). They should be very close, no user visible differences (except for bug fixes, obviously).

The overwhelming majority of programs link dynamically against their libraries (only one copy of the library on disk and in memory, commonly used symbols will be available for all, giving better performance), so that in particular a fix to a library is picked up next time the program is started after updating it. Only in very rare cases this could need a recompile of the program itself (if e.g. a inline function or a macro in a header turns out to be wrong in a damaging way).

Statically linked programs contain the code of the library (something increasingly rare!) could be vulnerable if they happen to use the broken code in the library.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.