Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

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

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

Attachment: pgpnwOMPc3SEM.pgp
Description: PGP signature