Как показать все общие библиотеки, используемые исполняемыми файлами в Linux?
https://stackoverflow.com/questions/50159
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я хотел бы знать, какие библиотеки используются исполняемыми файлами в моей системе.Более конкретно, я хотел бы ранжировать, какие библиотеки используются чаще всего, а также двоичные файлы, которые их используют.Как я могу это сделать?
Решение
- Использование
lddчтобы перечислить общие библиотеки для каждого исполняемого файла. - Очистка выходных данных
- Сортировать, вычислять количество, сортировать по количеству
Чтобы найти ответ для всех исполняемых файлов в каталоге "/bin":
find /bin -type f -perm /a+x -exec ldd {} \; \
| grep so \
| sed -e '/^[^\t]/ d' \
| sed -e 's/\t//' \
| sed -e 's/.*=..//' \
| sed -e 's/ (0.*)//' \
| sort \
| uniq -c \
| sort -n
Измените "/bin" выше на "/" для поиска по всем каталогам.
Выходные данные (только для каталога /bin) будут выглядеть примерно так:
1 /lib64/libexpat.so.0
1 /lib64/libgcc_s.so.1
1 /lib64/libnsl.so.1
1 /lib64/libpcre.so.0
1 /lib64/libproc-3.2.7.so
1 /usr/lib64/libbeecrypt.so.6
1 /usr/lib64/libbz2.so.1
1 /usr/lib64/libelf.so.1
1 /usr/lib64/libpopt.so.0
1 /usr/lib64/librpm-4.4.so
1 /usr/lib64/librpmdb-4.4.so
1 /usr/lib64/librpmio-4.4.so
1 /usr/lib64/libsqlite3.so.0
1 /usr/lib64/libstdc++.so.6
1 /usr/lib64/libz.so.1
2 /lib64/libasound.so.2
2 /lib64/libblkid.so.1
2 /lib64/libdevmapper.so.1.02
2 /lib64/libpam_misc.so.0
2 /lib64/libpam.so.0
2 /lib64/libuuid.so.1
3 /lib64/libaudit.so.0
3 /lib64/libcrypt.so.1
3 /lib64/libdbus-1.so.3
4 /lib64/libresolv.so.2
4 /lib64/libtermcap.so.2
5 /lib64/libacl.so.1
5 /lib64/libattr.so.1
5 /lib64/libcap.so.1
6 /lib64/librt.so.1
7 /lib64/libm.so.6
9 /lib64/libpthread.so.0
13 /lib64/libselinux.so.1
13 /lib64/libsepol.so.1
22 /lib64/libdl.so.2
83 /lib64/ld-linux-x86-64.so.2
83 /lib64/libc.so.6
Редактировать - Удален "grep -P"
Другие советы
У меня не было ldd в моем наборе инструментов ARM, поэтому я использовал objdump:
$(ПЕРЕКРЕСТНАЯ КОМПИЛЯЦИЯ)objdump -p
Например:
objdump -p /usr/bin/python:
Dynamic Section:
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libutil.so.1
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libz.so.1
NEEDED libm.so.6
NEEDED libc.so.6
INIT 0x0000000000416a98
FINI 0x000000000053c058
GNU_HASH 0x0000000000400298
STRTAB 0x000000000040c858
SYMTAB 0x0000000000402aa8
STRSZ 0x0000000000006cdb
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
PLTGOT 0x0000000000832fe8
PLTRELSZ 0x0000000000002688
PLTREL 0x0000000000000007
JMPREL 0x0000000000414410
RELA 0x0000000000414398
RELASZ 0x0000000000000078
RELAENT 0x0000000000000018
VERNEED 0x0000000000414258
VERNEEDNUM 0x0000000000000008
VERSYM 0x0000000000413534
чтобы узнать, какие библиотеки использует двоичный файл, используйте ldd
ldd path/to/the/tool
Вам пришлось бы написать небольшой сценарий командной строки, чтобы перейти к вашей общесистемной разбивке.
В Linux я использую:
lsof -P -T -p Application_PID
Это работает лучше, чем ldd когда исполняемый файл использует загрузчик, отличающийся от стандартного
Проверка зависимостей исполняемой программы от разделяемой библиотеки
Чтобы узнать, от каких библиотек зависит конкретный исполняемый файл, вы можете использовать команду ldd .Эта команда вызывает динамический компоновщик, чтобы выяснить библиотечные зависимости исполняемого файла.
> $ ldd /путь/к/программе
Обратите внимание, что НЕ рекомендуется запускать ldd с любым ненадежным сторонним исполняемым файлом, поскольку некоторые версии ldd могут напрямую вызывать исполняемый файл для определения зависимостей его библиотеки, что может представлять угрозу безопасности.
Вместо этого более безопасным способом показать зависимости библиотеки неизвестного двоичного файла приложения является использование следующей команды.
$ objdump -НЕОБХОДИМ p /путь/к/программе | grep
readelf -d рекурсия
redelf -d выдает результат, аналогичный objdump -p который был упомянут на: https://stackoverflow.com/a/15520982/895245
Но имейте в виду, что динамические библиотеки могут зависеть от других динамических библиотек, поэтому вам придется выполнять рекурсию.
Пример:
readelf -d /bin/ls | grep 'NEEDED'
Пример вывода:
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [libacl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Тогда:
$ locate libselinux.so.1
/lib/i386-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libselinux.so.1
/mnt/debootstrap/lib/x86_64-linux-gnu/libselinux.so.1
Выберите один из них и повторите:
readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'
Выборочный вывод:
0x0000000000000001 (NEEDED) Shared library: [libpcre.so.3]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
И так далее.
/proc/<pid>/maps для запущенных процессов
Это полезно для поиска всех библиотек, используемых в данный момент запущенными исполняемыми файлами.Например.:
sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u
показывает все загруженные в данный момент динамические зависимости init (PID 1):
/lib/x86_64-linux-gnu/ld-2.23.so
/lib/x86_64-linux-gnu/libapparmor.so.1.4.0
/lib/x86_64-linux-gnu/libaudit.so.1.0.0
/lib/x86_64-linux-gnu/libblkid.so.1.1.0
/lib/x86_64-linux-gnu/libc-2.23.so
/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libdl-2.23.so
/lib/x86_64-linux-gnu/libkmod.so.2.3.0
/lib/x86_64-linux-gnu/libmount.so.1.1.0
/lib/x86_64-linux-gnu/libpam.so.0.83.1
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
/lib/x86_64-linux-gnu/libpthread-2.23.so
/lib/x86_64-linux-gnu/librt-2.23.so
/lib/x86_64-linux-gnu/libseccomp.so.2.2.3
/lib/x86_64-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
Этот метод также показывает библиотеки, открытые с помощью dlopen, протестированный с помощью эта минимальная настройка изрубленный с помощью sleep(1000) в Ubuntu 18.04.
Смотрите также: https://superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089
В системе UNIX предположим, что двоичным (исполняемым) именем является test .Затем мы используем следующую команду, чтобы перечислить библиотеки, используемые в тесте
ldd test
В OS X по умолчанию нет ldd, objdump или lsof.В качестве альтернативы попробуйте otool -L:
$ otool -L `which openssl`
/usr/bin/openssl:
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
В этом примере, используя which openssl заполняет полный путь для данного исполняемого файла и текущей пользовательской среды.
С ldd вы можете получить библиотеки, которые используют инструменты.Чтобы ранжировать использование библиотек для набора инструментов, вы можете использовать что-то вроде следующей команды.
ldd /bin/* /usr/bin/* ... | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c
(Здесь sed удаляет все строки, которые не начинаются с табуляции, и отфильтровывает только сами библиотеки.С sort | uniq -c вы получаете каждую библиотеку с подсчетом, указывающим, сколько раз это происходило.)
Возможно, вы захотите добавить sort -g в конце, чтобы получить библиотеки в порядке использования.
Обратите внимание, что вы, вероятно, получите строки из двух небиблиотечных строк с помощью приведенной выше команды.Один из статических исполняемых файлов ("не динамический исполняемый файл") и один без какой-либо библиотеки.Последнее является результатом linux-gate.so.1 это не библиотека в вашей файловой системе, а библиотека, "поставляемая" ядром.
в ubuntu печать пакетов, связанных с исполняемым файлом
ldd имя_исполняемого файла|awk '{напечатать $3}'|xargs dpkg -S |awk -F ":" '{напечатать $1}''
Еще одним вариантом может быть просто чтение файла, расположенного по адресу
/proc/<pid>/maps
Например, если идентификатор процесса равен 2601, то команда
cat /proc/2601/maps
И на выходе получается что-то вроде
7fb37a8f2000-7fb37a8f4000 r-xp 00000000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37a8f4000-7fb37aaf3000 ---p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf3000-7fb37aaf4000 r--p 00001000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf4000-7fb37aaf5000 rw-p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf5000-7fb37aafe000 r-xp 00000000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37aafe000-7fb37acfd000 ---p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfd000-7fb37acfe000 r--p 00008000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfe000-7fb37acff000 rw-p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acff000-7fb37ad1d000 r-xp 00000000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37ad1d000-7fb37af1d000 ---p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1d000-7fb37af1e000 r--p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1e000-7fb37af1f000 rw-p 0001f000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1f000-7fb37af21000 r-xp 00000000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37af21000-7fb37b121000 ---p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b121000-7fb37b122000 r--p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b122000-7fb37b123000 rw-p 00003000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
Я нашел этот пост очень полезным, поскольку мне нужно было исследовать зависимости из библиотеки, поставляемой сторонним поставщиком (32 или 64-разрядные пути выполнения).
Я собрал рекурсивный bash-скрипт Q & D, основанный на предложении 'readelf -d' в дистрибутиве RHEL 6.
Он очень простой и будет проверять каждую зависимость каждый раз, даже если она могла быть протестирована ранее (т. е. очень подробная).Вывод тоже очень простой.
#! /bin/bash
recurse ()
# Param 1 is the nuumber of spaces that the output will be prepended with
# Param 2 full path to library
{
#Use 'readelf -d' to find dependencies
dependencies=$(readelf -d ${2} | grep NEEDED | awk '{ print $5 }' | tr -d '[]')
for d in $dependencies; do
echo "${1}${d}"
nm=${d##*/}
#libstdc++ hack for the '+'-s
nm1=${nm//"+"/"\+"}
# /lib /lib64 /usr/lib and /usr/lib are searched
children=$(locate ${d} | grep -E "(^/(lib|lib64|usr/lib|usr/lib64)/${nm1})")
rc=$?
#at least locate... didn't fail
if [ ${rc} == "0" ] ; then
#we have at least one dependency
if [ ${#children[@]} -gt 0 ]; then
#check the dependeny's dependencies
for c in $children; do
recurse " ${1}" ${c}
done
else
echo "${1}no children found"
fi
else
echo "${1}locate failed for ${d}"
fi
done
}
# Q&D -- recurse needs 2 params could/should be supplied from cmdline
recurse "" !!full path to library you want to investigate!!
перенаправьте выходные данные в файл и введите grep для "найдено" или "сбой"
Используйте и модифицируйте, конечно, на свой страх и риск, по своему усмотрению.
