Add ability to change dll search path from within the process

[szymonwieloch]

On Windows it is doable using the SetDllDirectory() function, on POSIX probably modifying the LD_LIBRARY_PATH with setenv could do the trick.

[ahmed-masud]

You may not want to do this, or somehow provide limits on how this may be done.

For most implementations of libdl that I have seen, LD_LIBRARY_PATH is only checked at the beginning of the execution of the main process and slurped up by dl, it is not referenced again (i.e. later on).

Let's say this was not the case, then, it would have unintentional security and functional consequences, like an external entity overriding the locations where plugins are loaded from and could inject bad code into a running process; or a poorly written external DLL could start doing weird things.

[szymonwieloch]

Hi @ahmed-masud ! We have a case in other project that requires use of SetDllDirectory(). This is officially recommended by npcap library in one case. I would prefer to add this to dlopen but only if this is a platform-wide functionality. I have searched for POSIX alternatives to SetDllDirectory and found nothing. Do you know any better way? It would be really helpful to us.

[ahmed-masud]

1. Can you share how it's recommended by npcap?

The trouble with SetDllDirectory in Windows is also security issues.

The SetDllDirectory function affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions. It also effectively disables safe DLL search mode while the specified directory is in the search path.

Rather than trying to sit under SetDllDirectory I would recommend sitting above it. What I mean by that is to create an abstraction that ensures secure loading which uses SetDllDirectory or explicit ld.so for ELF (e.g. rpath etc) and manages the searching internally. This is better because in both cases it would allow plugins for processes that have escalated privileges and stay secure.

I am creating a plugin extension for a rather complex set of plugins for a rust project where I am using dlopen, I am happy to contribute my plugin code, and the approach and discuss why I chose to do things a particular way.

[szymonwieloch]

@ahmed-masud

Here is npcap documentation:
https://nmap.org/npcap/guide/npcap-devguide.html

The problem is that npcap tries to mimic wpcap. It also has wpcap.dll and Packet.dll. If wpcap and npcap coexist, wpcap dlls are placed in Windows/system32 directory, npcap dlls are placed in Windows/system32/npcap directory. The rules of windows dll dependencies make Windows open Packet.dll always from Windows/system32 directory, so it always uses wpcap dll. This breaks npcap since it only works with its own versio of Packet.dll. The solution is to use SetDllDirectory() To make Windows load Packet.dll from Windows/system32/npcap directory.

I was also thinking about adding plugin extension to dlopen, there is even a task for it :-). I'll be happy to see the code.