On Oct 24 22:16, Christian Franke wrote:
> Corinna Vinschen wrote:
> >[Christian, please chime in]
> >
> >On Oct 24 20:41, Denis Excoffier wrote:
> >>> From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
> >>>makes sense that the system DLLs in /bin cannot be overridden, unless
> >>>it's an installation issue which should be covered by looking into the
> >>>application installation dir first.
> >>Instead of adding the lookup of /usr/bin before the PATH, you could add
> >>it afterwards?
> >No. You don't expect this kind of flexibility in the Win32 API, do you?
>
> [The *LIBPATH variables from MS OS/2 (1987) never made it to Win API :-]
>
>
> >The way it works is, there's a call SetDllDirectory which replaces the "."
> >in the DLL search path with the directory given as argument. The search
> >order is always this:
> >
> > application dir
> > dir given in SetDllDirecory (Cygwin's bin)
> > system dirs
> > $PATH
> >
> >>Or do you mean that my use is bad practice for security
> >>reasons? That there might be some unexpected DLL somewhere in the PATH?
> >>IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
> >>not otherwise.
> >Not quite. LD_LIBRARY_PATH is only ignored if the excutable is a
> >suid/sgid executable. Unfortunately we don't have LD_LIBRARY_PATH at
> >all when running execve (but we have in dlopen).
> >
> >>>Having said that, moving your DLLs into the application dir is really
> >>>not an option?
> >>Oh yes, i use it all the time. It is the job of 'make install' to also
> >>install the appropriate DLLs. The point here is for 'make check'.
> >Yeah.
> >
> >Sigh.
> >
> >I don't like the idea either that this simple change breaks existing
> >scenarios. I'm inclined to revert this change.
> >
> >Christian, would you mind terribly to re-add the tweak to postfix
> >to set $PATH?
> >
>
> No problem.
Thanks, I'm relieved.
> Another possible solution:
> Check for e.g. CYGWIN_DLLPATH environment variable before calling
> SetDllDirectory().
>
> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> else if set to ".", do nothing.
> else call SetDllDirectory(CYGWIN_DLLPATH);
>
> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
> check'.
Hmm. This requirement to set CYGWIN_DLLPATH would be far from obvious
for the user, though.
> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a
> real search path in CYGWIN_DLLPATH.
Per MSDN, AddDllDirectory only works for LoadLibrary{Ex}, and the DLL
search order when using SetDefaultDllDirectories looks entirely
different from the other default search orders(*).
Even if it works for CreateProcess as well, the probably worst problem
is that $PATH is not evaluated anymore.
OTOH, this might allow us to redefine the DLL search path in a way which
enables LD_LIBRARY_PATH handling for Cygwin, but a patch to use this
stuff would be pretty intrusive.
Thanks,
Corinna
(*)
http://msdn.microsoft.com/en-us/library/windows/desktop/hh310515%28v=vs.85%29.aspx
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpCHt_0YjaxV.pgp
Description: PGP signature
