识别正在使用我刚替换的库的旧版本的正在运行的程序

9

在安装更新以解决CVE-2014-0160（OpenSSL Heartbleed错误）之后，我必须小心重启可能正在使用libssl的所有内容-许多服务（例如Apache和我的VPN软件）仍然加载了旧的易受攻击的libssl ，而我的包裹管理员没有尝试纠正这一问题。

这让我开始思考：更新共享库后，如何可靠地找出当前正在运行的程序中链接了旧版本的库？我确信必须有一种方法可以在链接器级别或文件描述符级别查询正在运行的进程，以确定它们已加载的给定共享库的实例与当前磁盘上的实例是否相同。

upgrade libraries dynamic-linking

— gie
source

9

我发现了两种方法可以做到这一点：

特定于Debian的文件，列出了进程持有的大多数已删除/替换的文件（某些文件是瞬时文件，例如/tmp），该文件debian-goodies包包含checkrestart，它完成了我所描述的工作，通过抓取lsoffind 的输出来完成打开磁盘上已丢失或替换的文件。它标识所涉及的进程以及（如果可能）它们所属的程序包以及可用于重新启动它们的任何初始化脚本。该-v选项将识别相关文件。
通用手册允许指定您担心的文件：您可以查看的输出lsof以标识已删除或已替换文件的打开文件句柄。在的输出中lsof -nnP，该文件似乎DEL在第四列中由标识。您可以执行类似lsof -nnP | grep DEL.*libssl.so查找特定库（在此情况下为OpenSSL）的过时句柄的操作。这可能高度取决于您使用的lsof的特定版本以及程序包管理器的行为，因此请谨慎操作。
```
pluto      3592       root  DEL       REG      202,0               98831 /lib/i386-linux-gnu/libssl.so.1.0.0
pluto      3604       root  DEL       REG      202,0               98831 /lib/i386-linux-gnu/libssl.so.1.0.0
```

— gie
source

3

在Linux上的一种快速而肮脏的方法（感谢 Lekensteyn）：

grep '/usr/lib/libssl1.*(deleted)' /proc/*/maps

为了进行精确的解析，您可以lsof使用-F选项进行调用以获取可解析的输出。包括f用于过滤已删除文件fDEL的n字段（）和用于获取文件路径的字段。请注意，下面的代码片段扼杀了包含换行符的文件名。

lsof -F pfn | awk '
    /^p/ {pid=substr($0,2)}
    /^fDEL$/ {getline; if (/n\/usr\/lib\/libssl1\.0\.1.*(deleted)$/) print pid}
'

— 吉尔斯“别再邪恶了”
source