View shared libraries linux

Get a list of all shared libraries that a running service is using in Ubuntu [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

linux-vdso.so.1 => (0x00007ffe5eb7a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa0b1a48000)
/lib64/ld-linux-x86-64.so.2 (0x000055a297a76000)

1234: /usr/sbin/acpid
0000000000400000 44K r-x— acpid
000000000060a000 4K r—- acpid
000000000060b000 4K rw— acpid
000000000060c000 4K rw— [ anon ]
00000000020ce000 132K rw— [ anon ]
00007f0ac06c7000 1788K r-x— libc-2.23.so
00007f0ac0886000 2048K —— libc-2.23.so
00007f0ac0a86000 16K r—- libc-2.23.so
00007f0ac0a8a000 8K rw— libc-2.23.so
00007f0ac0a8c000 16K rw— [ anon ]
00007f0ac0a90000 152K r-x— ld-2.23.so
00007f0ac0caa000 12K rw— [ anon ]
00007f0ac0cb3000 8K rw— [ anon ]
00007f0ac0cb5000 4K r—- ld-2.23.so
00007f0ac0cb6000 4K rw— ld-2.23.so
00007f0ac0cb7000 4K rw— [ anon ]
00007ffcacbda000 132K rw— [ stack ]
00007ffcacbfb000 8K r—- [ anon ]
00007ffcacbfd000 8K r-x— [ anon ]
ffffffffff600000 4K r-x— [ anon ]
total 4400K

Also in the process, I learned about what exactly are shared libraries and how are they handled in Linux on a broad level.

Now here are the things that I need help with:

1. If we look at the output of each of the solutions above, libc.so.6 is present in the output of solutions 1, 2 and 4 but not in 3. Also the output of solution 1 above reports inux-vdso.so.1 and /lib64/ld-linux-x86-64.so.2 as well which no other solution reports. So which of these solutions should be taken as the accurate one.
2. As per my understanding, shared libraries are loaded into the memory by the loader at runtime. Also, on demand a process can load any more shared libraries when ever needed. Am I right or wrong here ? In case right, the shared libraries being used by any given process could always be dynamic. So, if I really need to know the shared libraries being used by a process, will I need to poll the process all the time to figure this out ? (Am sure there is much better /elegant solution to this)
3. Solution 1, the ldd approach, is something I would want to avoid because of the inherent security risk it has (depending on the version of the ldd being used) of starting an executable itself to figure out it’s shared libraries.

So what is the best approach to figure out the shared libraries being used by a process?

2 Answers 2

libc.so.6 is present in the output of solutions 1, 2 and 4 but not in 3.

libc.so.6 is a symlink to libc-2.23.so so it is present, albeit in a different form.

and /lib64/ld-linux-x86-64.so.2 as well which no other solution reports.

Also the output of solution 1 above reports inux-vdso.so.1

This is a dummy shared lib which does not exist but is emulated by kernel to increase performance of some library functions. I guess 3 has it in

ffffffffff600000 4K r-x-- [ anon ] 

which of these solutions should be taken as the accurate one.

2 and 4 are equivalent. They are inferior to 1 and 3 because they report only direct dependencies of your app (not transitive dependencies of it’s dependants). Further, 1 is inferior to 3 because it won’t report dynamically loaded libs (via dlopen ).

Also, on demand a process can load any more shared libraries when ever needed. Am I right or wrong here ?

Yup, that’s used to implement e.g. plugins.

So, if I really need to know the shared libraries being used by a process, will I need to poll the process all the time to figure this out ? (Am sure there is much better /elegant solution to this)

No, there is no easier solution. You could check whether app calls dlopen (by scanning output of readelf —dyn-syms -W ) — if it doesn’t you are most probably fine (some really clever apps may load libs themselves via mmap , etc. but this is so rare that is fine to ignore).

If app does call dlopen than the best thing you can do is use solution 3. This is obviously incomplete as app may load new libs at any time, depending on it’s algorithm (and there’s generally no way to figure it out statically as that would be equivalent to solving the halting problem).

One approximate solution for finding potentially dlopen -ed libs would be to scan all strings in app (by running strings on it) and extracting everything that looks like a library name. Of course this won’t catch the situations where library name is generated dynamically (e.g. read from some config file).

Solution 1, the ldd approach, is something I would want to avoid because of the inherent security risk it has (depending on the version of the ldd being used) of starting an executable itself to figure out it’s shared libraries.

I don’t think executable is started i.e. no app or libs code gets run.

So what is the best approach to figure out the shared libraries being used by a process?

I’d got with no. 3 (which has many equivalent variants e.g. scanning /proc/PID/maps or lsof as suggested in other post). Depending on how inclined you are about dlopen , you can also scan strings for potentially loaded libs but IMHO that’s an overkill in majority of cases.

Источник

How do I get a list of shared library filenames under Linux?

Is there a GNU Linux built-in for getting a list of the filenames of shared libraries? I have considered parsing the output of ldconfig -p . However, I’m not sure about consistency in output from system to system. I am already aware that I could use find but given that the linker / loader has a cache of libraries and locations, it seems more efficient to use it in some way. Additionally, the paths that the linker / loader searches are the only ones I’m concerned with—i.e libraries that have been processed by ldconfig .

1 Answer 1

If you want to catch them all, there is no other choice but to do full filesystem traversals. ldconfig knows only about the libraries in the standard paths and the extra paths it is configured to look in (usually defined in /etc/ld.so.conf* ). The usual suspect places where other libraries can be found are $HOME and /opt , though there is no limit, especially when people build applications themselves.

If you don’t trust the output of ldconfig -p , you can parse its cache directly. It’s binary, but using strings removes all the garbage (5 so /lib/ matches):

On my system, they both give the same results, which I verified with this quicky:

a=$(ldconfig -p | awk -F'> ' '' | sort); # get them to the same format b=$(strings -n5 /etc/ld.so.cache | sort -u); echo -e "$a\n$b\n$b" | sort | uniq -u 

Which checked if any library on the ldconfig -p list was not mentioned in the cache. Nothing was returned.

Источник

Understanding Shared Libraries in Linux

In programming, a library is an assortment of pre-compiled pieces of code that can be reused in a program. Libraries simplify life for programmers, in that they provide reusable functions, routines, classes, data structures, and so on (written by another programmer), which they can use in their programs.

For instance, if you are building an application that needs to perform math operations, you don’t have to create a new math function for that, you can simply use existing functions in libraries for that programming language.

Examples of libraries in Linux include libc (the standard C library) or Glibc (GNU version of the standard C library), libcurl (multiprotocol file transfer library), libcrypt (library used for encryption, hashing, and encoding in C), and many more.

Linux supports two classes of libraries, namely:

• Static libraries – are bound to a program statically at compile time.
• Dynamic or shared libraries – are loaded when a program is launched and loaded into memory and binding occurs at run time.

Dynamic or shared libraries can further be categorized into:

• Dynamically linked libraries – here a program is linked with the shared library and the kernel loads the library (in case it’s not in memory) upon execution.
• Dynamically loaded libraries – the program takes full control by calling functions with the library.

Shared Library Naming Conventions

Shared libraries are named in two ways: the library name (a.k.a soname) and a “filename” (absolute path to file which stores library code).

For example, the soname for libc is libc.so.6: where lib is the prefix, c is a descriptive name, so means shared object, and 6 is the version. And its filename is: /lib64/libc.so.6. Note that the soname is actually a symbolic link to the filename.

Locating Shared Libraries in Linux

Shared libraries are loaded by ld.so (or ld.so.x) and ld-linux.so (or ld-linux.so.x) programs, where x is the version. In Linux, /lib/ld-linux.so.x searches and loads all shared libraries used by a program.

A program can call a library using its library name or filename, and a library path stores directories where libraries can be found in the filesystem. By default, libraries are located in /usr/local/lib, /usr/local/lib64, /usr/lib and /usr/lib64; system startup libraries are in /lib and /lib64. Programmers can, however, install libraries in custom locations.

The library path can be defined in /etc/ld.so.conf file which you can edit with a command-line editor.

The line(s) in this file instruct the kernel to load file in /etc/ld.so.conf.d. This way, package maintainers or programmers can add their custom library directories to the search list.

If you look into the /etc/ld.so.conf.d directory, you’ll see .conf files for some common packages (kernel, mysql, and postgresql in this case):

# ls /etc/ld.so.conf.d kernel-2.6.32-358.18.1.el6.x86_64.conf kernel-2.6.32-696.1.1.el6.x86_64.conf mariadb-x86_64.conf kernel-2.6.32-642.6.2.el6.x86_64.conf kernel-2.6.32-696.6.3.el6.x86_64.conf postgresql-pgdg-libs.conf

If you take a look at the mariadb-x86_64.conf, you will see an absolute path to package libraries.

# cat mariadb-x86_64.conf /usr/lib64/mysql

The method above sets the library path permanently. To set it temporarily, use the LD_LIBRARY_PATH environment variable on the command line. If you want to keep the changes permanent, then add this line in the shell initialization file /etc/profile (global) or ~/.profile (user-specific).

# export LD_LIBRARY_PATH=/path/to/library/file

Managing Shared Libraries in Linux

Let us now look at how to deal with shared libraries. To get a list of all shared library dependencies for a binary file, you can use the ldd utility. The output of ldd is in the form:

library name => filename (some hexadecimal value) OR filename (some hexadecimal value) #this is shown when library name can’t be read

This command shows all shared library dependencies for the ls command.

# ldd /usr/bin/ls OR # ldd /bin/ls

Sample Output

linux-vdso.so.1 => (0x00007ffebf9c2000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003b71e00000) librt.so.1 => /lib64/librt.so.1 (0x0000003b71600000) libcap.so.2 => /lib64/libcap.so.2 (0x0000003b76a00000) libacl.so.1 => /lib64/libacl.so.1 (0x0000003b75e00000) libc.so.6 => /lib64/libc.so.6 (0x0000003b70600000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003b70a00000) /lib64/ld-linux-x86-64.so.2 (0x0000561abfc09000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b70e00000) libattr.so.1 => /lib64/libattr.so.1 (0x0000003b75600000)

Because shared libraries can exist in many different directories, searching through all of these directories when a program is launched would be greatly inefficient: which is one of the likely disadvantages of dynamic libraries. Therefore a mechanism of caching is employed, performed by the program ldconfig.

By default, ldconfig reads the content of /etc/ld.so.conf, creates the appropriate symbolic links in the dynamic link directories, and then writes a cache to /etc/ld.so.cache which is then easily used by other programs.

This is very important especially when you have just installed new shared libraries or created your own, or created new library directories. You need to run the ldconfig command to effect the changes.

# ldconfig OR # ldconfig -v #shows files and directories it works with

After creating your shared library, you need to install it. You can either move it into any of the standard directories mentioned above and run the ldconfig command.

Alternatively, run the following command to create symbolic links from the soname to the filename:

# ldconfig -n /path/to/your/shared/libraries

To get started with creating your own libraries, check out this guide from The Linux Documentation Project(TLDP).

That’s all for now! In this article, we gave you an introduction to libraries and explained shared libraries, and how to manage them in Linux. If you have any queries or additional ideas to share, use the comment form below.

Источник