Re: Cannot exec() program outside of /bin if PATH is unset

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Oct 10 14:13, Arjen Markus wrote:
> 2014-10-10 13:22 GMT+02:00  <tednolan>:
> >>2014-10-10 13:24 GMT+02:00 Jan Nijtmans <...>:
> >>> 2014-10-10 12:34 GMT+02:00 Corinna Vinschen <...>:
> >>>> On Oct  9 11:46, tednolan.net wrote:
> >>>>> I'm pretty sure I've got some programs loading Tcl extensions that
> >>>>> cd into the directory with the extension dlls, load the extension and then
> >>>>> change back to where ever they were.
> >>>>
> >>>> Hmm.  If so, it's quite a weird way to handle this, rather than
> >>>> loading the modules with full path.
> >>>>
> >>>> Is that a Tcl "feature", or is it how certain Tcl apps are implemented?
> >>>> I can't really believe the former...
> >>>
> >>> This is certainly not a Tcl "feature"!  The standard Tcl extension
> >>> mechanism always uses the full path simply because Tcl
> >>> cannot depend on platform-specific ways to search for
> >>> such libraries elsewhere.
> >>>
> >>> I'm willing to test this;I don't believe such a change
> >>> will break anything in my Tcl environment.
> >>>
> >>> Regards,
> >>>        Jan Nijtmans
> >
> > Hmm,
> >
> > It's been a while, but I think it is something like the extension is
> > a DLL, but it depends on another DLL.  Consider for instance, mysqltcl.
> > If you want to deploy that, you need the mysqltcl.dll and the mysql dll,
> > so you either have to be in the same dir when you load the extension,
> > or put that dir in PATH.
> >
> > Unfortunately, I can't run a test release on my work machine, or take
> > my work progs home.
> 
> Right, that makes sense. There is indeed no way for the package
> manager to handle that scenario without external help, such as a PATH
> variable that includes the various directories these extra DLLs reside
> in.

There might be a potential workaround.  Given that Cygwin Tcl calls
dlopen to load DLLs, we have this somewhat under control.

The default DLL search algorithm searches the application dir for
dependent DLLs.  But there's a LoadLibraryEx flag called
LOAD_WITH_ALTERED_SEARCH_PATH.  When using this flag, and the DLL is
given with full path, the application dir in the DLL search path is
replaced by the directory of the DLL.  Thus, dependent DLLs will be
searched in the same dir the original DLL has been loaded from.

This could be utilized in dlopen.  If the DLL is given with no path, and
if LoadLibrary failes, create the full path to the DLL and call
LoadLibraryEx (full_path, LOAD_WITH_ALTERED_SEARCH_PATH).  DLLs in /bin
are taken care of by the SetDllDirectory call we're talking about here.

This is no 100% safe bet, I guess.  It would fail to load DLLs in
scenarios where DLLs depend on other DLLs from the current dir as well
as from the application dir, and the application dir is not /bin.  Just
how realistic is this scenario in a Cygwin environment?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp67ZDk8i3tL.pgp
Description: PGP signature