Use LoadLibraryEx to be able to find dependencies in the DLL:s directory #140
Conversation
…at it look for dependencies in the directory of the DLL
|
Hello @qpernil and thanks for the PR! I'll need to take a closer look at the documentation of |
|
Yes, our own ykcs11, which has a couple of dependencies that get installed
in the same directory as the pkcs11 dll itself.
The workaround I use today is to put that installation directory on the
PATH. With my proposed change I wouldn't have to do that.
I suppose I could also copy the pkcs11 dll and it's dependencies to the
dotnet core application's directory, but in my case those are not related
so isn't a good solution.
You can find the pkcs11 implementation I'm referring to here:
https://developers.yubico.com/yubico-piv-tool/Releases/
However, I don't think this is specific to our PKCS11 implementation.
LoadLibrary only seems to include the calling application's path (in
addition to system-wide library path) in the directories it searches which
doesn't make a lot of sense when used in a .net application. I tested this
on dotnet core 2.0 and 3.0 (i haven't tested with classic .NET)
Best regards
Per
…On Fri, Jan 31, 2020 at 9:43 PM Jaroslav Imrich ***@***.***> wrote:
Hello @qpernil <https://github.com/qpernil> and thanks for the PR!
I'll need to take a closer look at the documentation of LoadLibraryEx
function and carefully consider both compatibility and security impact of
this change. Did you use Pkcs11Interop with any specific PKCS#11
implementation that needed this change?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#140?email_source=notifications&email_token=ANHMTEQS6APKVEQNW7YNGRTRASEOJA5CNFSM4KOGUGC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKP6GKY#issuecomment-580903723>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANHMTESGXPCPN535W4MDMBLRASEOJANCNFSM4KOGUGCQ>
.
--
*--*
Per Nilsson
Firmware Engineer | Yubico <https://www.yubico.com/>
Phone: +46 720 77 8240
|
|
Have you had a chance to look at this yet ? |
|
Sorry not yet. I'll try this weekend. |
|
I'll just leave these relevant docs here: |
|
Re-reading the docs it seems one should use Path.GetFullPath(fileName) before calling LoadLibraryEx as it's apparently undefined to call it with the alternate search path flag and a non-absolute path. |
…ryEx with altered search path and a non-absolute path is undefined behaviour
|
I hope you're OK with that I slightly modified your implementation in #143 because I'm regularly using relative paths in Pkcs11Admin application. I'm going to test that code now with a few modules to confirm it does not break anything. Could you please also test the code in |
|
Wouldn't it work as I implemented it anyway ? I.e. resolving the path to absolute will give the same outcome (LoadLibraryEx will resolve the relative path anyway), just with less code ? Just thinking, I'm fine with your way as well. An unrelated thing you may have seen already: They now support platform-independent dynamic loading of libraries directly in dotnet core. I guess you might not be able to use it because you need to support older versions, including the 'classic' dotnet. |
|
I will test your version later today, thx for your feedback ! |
|
Closing this PR as jariq has a better solution. Thx ! |
No, it wouldn't because In my previous comment I wrote that "I'm regularly using relative paths in Pkcs11Admin application" but now I see that relative is not correct term here. I'll try to explain with more details: Let's assume there's I hope this better explains my reasons for an alternative implementation. |
If the DLL you point to has dependencies in the same directory it won't load with LoadLibrary, as that directory is not on the library path. LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flags searches that directory, so it works as one would expect.