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]

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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. Commented Jan 30, 2017 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. Commented Jan 30, 2017 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? Commented Jan 30, 2017 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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.