1

It's quite common to have security updates arise for various system libraries on servers I administer (Linux, mostly Debian and Ubuntu). I can run the updates easily enough, but that often leaves running applications still linked against the old versions of the libraries and potentially still vulnerable.

Is there a way to list running applications which are linked against a particular library (probably before running the update), or (much better) to list applications which are linked against library files that are no longer linked in the file system? (run after the update)

It would be useful to have something I could run in advance of updates, but that doesn't seem to fit into a system maintenance workflow all that easily, and it would be easy to not do it consistently. It would be better I think to regularly check for running executables linked against libraries that are no longer present in the system. Maybe that can be pulled out of /proc somehow?

[For about a zillion extra points, provide a solution which also finds such situations for processes running inside containers, virtualenv, etc]

2

UPDATE: Here's a Bash script that I think does more of what you're asking for. It will scan currently running processes and list RPM packages that contain libraries that are currently loaded in memory for those processes.

#!/bin/bash

procs=$(find /proc -maxdepth 1 -type d -name "[0-9]*" | sed 's@/proc/@@')

for proc in $procs[*]; do
  if [ ! -f /proc/$proc/cmdline ]; then
    continue
  fi

  cmd=$(cat /proc/$proc/cmdline | sed 's/[\s\n]+//g')

  if [ -z "$cmd" ]; then
    continue
  fi

  echo "**** Scanning pid ($proc): $cmd"
  echo

  echo "Dependent RPM Packages:"
  (
    libs=$(sudo lsof -p $proc -a -d mem 2>/dev/null | awk '{print $NF}' | grep "\.so")
    for lib in $libs; do
      echo $(rpm -qf $lib)
    done
  ) | sort -u
  echo
done

You could write a simple Bash script to figure out which binaries are reliant on a particular library.

To get the list of binaries on disk affected:

#!/bin/bash

dir=$1
lib=$2

for bin in $(find $dir -type f -executable); do
  ldd $bin | grep -q "$lib" && echo $bin
done

Or in the case of running processes on the system you could grep ps -ef instead and use ldd the same way as above.

Depending on your flavor of Linux you could also find how a particular package update affects your system based on the libraries contained within it.

On a CentOS system you could do the following to get the list of shared libraries in a package:

$ rpm -ql zlib | grep "\.so"
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.2.7

Then you could again use ldd on system binaries to determine which binaries use the listed libraries.

  • This is useful, but something that could check what's linked to the running processes would be much better. Getting names/paths of executables and running ldd against them tells you what would be used if you restarted the binary, not what the running process is actually linking to now. – mc0e Jan 30 '17 at 4:36
  • Your newer script identifies the paths associated with linked libraries, but that's insufficient information with which to identify whether the library that's linked is the same as what's at that path now. Identifying packages that provide the library is not the goal. Rather I want to identify running processes that are still using old versions of libraries. – mc0e Jan 30 '17 at 13:36
  • It sounds like what you want is to be able to hash the library content in memory and compare that with a hash of the content stored on disk. Is that what you're trying to do? – mattops Jan 30 '17 at 18:34
0

The first part of an answer seems to be available in /proc/$PID/map_files/.

On my laptop, looking at the running thunderbird process, I can see entries like:

lr-------- 1 mc0e mc0e 64 Jan 30 15:51 7f8d54fe1000-7f8d55025000 -> /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6 (deleted)

It recognises that the linked version of the file is deleted, even though an updated version is in the same location.

There's a bit of scripting to do here, but it's pretty straightforward in the case of processes running directly on the host file system.

More investigation is still needed to understand how this will work for processes running in different name spaces.

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.