Netprobe fails to run X-* plugin due to shared library issues

If you setuid(2) or use capabilities(7) on a Netprobe it will ignore any LD_LIBRARY_PATH and only system directories and the current working directory will be searched, which in turn results in failure to load required dynamic libraries When setting up a Netprobe to run X-* plugins you can either run it as root or with fine-grained capabilities. Either of these methods will result in the LD_LIBRARY_PATH being ignored, which in turn results in a failure to load required dynamic libraries. This means a Netprobe running X-* plugins and others may not work correctly. Even the included libssl.so and libpcap.so may not be found if the Netprobe is started outside its installation directory.

Scope: All the information in this FAQ applies only to Linux. Other UNIX-type OSes, such as Solaris, have their own systems to deal with this scenario which may be subtly different. Nothing here applies to Windows. In certain conditions the Linux dynamic linker will ignore LD_LIBRARY_PATH and some other environment variables. From ld.so(8):

Secure-execution mode

For security reasons, the effects of some environment variables are

voided or modified if the dynamic linker determines that the binary

should be run in secure-execution mode.  This determination is made

by checking whether the AT_SECURE entry in the auxiliary vector (see

getauxval(3)) has a nonzero value.  This entry may have a nonzero

value for various reasons, including:

- The process's real and effective user IDs differ, or the real and

effective group IDs differ.  This typically occurs as a result of

executing a set-user-ID or set-group-ID program.

- A process with a non-root user ID executed a binary that conferred

permitted or effective capabilities.

- A nonzero value may have been set by a Linux Security Module.

This means that if the Netprobe binary has either SETUID or capabilities(7) set then only pre-configured directories are searched for shared library files. This matters for a number of plugins which load external libraries including the X-* plugins themselves - which are the primary reason for using elevated privileges on a Netprobe. On most systems the only directories searched are those pre-defined in /etc/ld.so.cache - generated using ldconfig - and the current directory. In most cases the Netprobe is executed in the installation directory and so that directory is searched for shared library files but if the Netprobe is executed from somewhere else, for example using the Best Practice Templates scripts such as netprobectl then the Netprobe will be started with a working directory different from the install location and so none of the shipped shared libraries will be found. There are a number of ways of working around this and the choice will be dependent on local installation practices and the combination of circumstances that most closely match:

1. Separate Netprobes for X-* plugins and others It may seem desirable to have a single Netprobe package that can be installed and used for all configurations but issues like the one detailed in this FAQ mean that it may be better to have a “normal” Netprobe installation and a separate one for X-* plugins where elevated privileges are required. However even in this case the Netprobe with capabilities may still have issues loading shared libraries that are not in the default search list of directories. In this case, assuming the list of shared libraries is small and the working directory of the Netprobe is different from the installation location, you can symlink all the shared libraries into the working directory using a command like:

ln -s PATHTOINSTALL/*.so .

2. Add all directories normally in LD_LIBRARY_PATH to the system-side ld.so.cache using ldconfig and appropriate config files Depending on the age and the distribution of the Linux system you can add all the directories required to the system-wide ld.so.cache. This is usually done by adding files to the /etc/ld.so.conf.d directory, e.g. netprobe-libs, which list one directory per line of places to search. This can then be read into the cache using ldconfig(8) as root or, on most systems, it will be read after reboot. The downside is that if there are multiple versions of the Netprobe installed then only the first directory and shared library with a specific name matched will be used.