Re: About the dll search algorithm of dlopen (patch-r3)

[Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>]

Hi Corinna,

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.

Thanks!

... 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?

/haubi/