-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.