This is the mail archive of the
mailing list for the Cygwin project.
Re: About the dll search algorithm of dlopen (patch-r3)
On 08/30/2016 03:35 PM, Corinna Vinschen wrote:
> On Aug 29 11:24, Michael Haubenwallner wrote:
>> On 08/26/2016 02:04 PM, Corinna Vinschen wrote:
>>> On Aug 25 19:48, Michael Haubenwallner wrote:
>>>> On 08/22/2016 08:37 PM, Corinna Vinschen wrote:
>>>>> (*) Yuk! Do we really, *really* want that? The redirection from
>>>>> /usr/lib to /usr/bin is only done for system libs, and only because
>>>>> otherwise we had trouble starting Cygwin from CMD or the Explorer
>>>>> GUI "Run..." box. We can't change this without breaking everything
>>>>> since we *do* depend on the Windows loader yet.
>>>>> However, as long as this is restricted to /usr/lib, /usr/bin, it's a
>>>>> closed system under control of "the distro". If you extend this to
>>>>> *any* external path ending in "lib", isn't it inherently dangerous
>>>>> to automate this under the hood, without the application's consent?
>>>>> Or, FWIW, the user's consent in case of LD_LIBRARY_PATH?
>>>> 've split into add_lib_searchdir (), used for "/usr/lib" only.
>>> Btw., I just noticed something interesting, independently of your patch.
>>> Consider the file /usr/bin/cygz.dll:
>>> - dlopen (libz.so) success
This one succeeds because of /usr/bin being the fallback path, but ...
>>> - dlopen (/usr/bin/libz.so) success
>>> - dlopen (/usr/lib/libz.so) fails
>>> That's pretty clear when looking through the code, but... wouldn't
>>> it make sense to allow that? If a path is given, and the path points
>>> to /usr/lib, search the file in /usr/bin as well?
>> Easy enough - but this should apply to any prefix IMO: While the
>> application specific prefix often isn't /usr - but something like
>> /usr/local or /opt/application, application specific libs may be
>> built & installed with libtool or something similar as well - at
>> least some tool that knows about installing the real dll into
>> <app-prefix>/bin (because of the missing Cygwin loader).
> You have a point there.
... I forgot about dlopen("libAPP.so") (without path): This I expect
to find <app-prefix>/bin/cygAPP.dll - which is the application dir.
>> But agreed, it makes sense doing /lib->/bin for the explicit path and
>> the /usr/lib default only and not for the environment-provided paths.
> It feels certainly more safe to restrict this to the system path for
> now. But... yeah, you have a point.
> Not well thought out, just an idea kicking around:
> Apart from the obvious system path handling, what if other lib->bin
> transitions only take place if the calling application is installed
> in that very bin dir...?
Interesting idea - might work indeed! Even for prefix=/usr, to
have consistent behaviour across different application prefixes.
For safety regarding the application dir: If one can write to the
application dir, couldn't one put a malicious kernel32.dll there
as well, and/or an empty application.exe.local for dll redirection?