[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[Christian, please chime in]

On Oct 24 20:41, Denis Excoffier wrote:
> > On 2014-10-24 13:02, Corinna Vinschen wrote:
> > On Oct 23 20:06, Denis Excoffier wrote:
> >> On 2014-10-22 11:23, Corinna Vinschen wrote:
> >>> 
> >>> - Drop the current working directory from the default DLL search path in
> >>> favor of Cygwin's /bin dir.
> >> I'm not so comfortable with this one.
> >> 
> >> I use
> >> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
> >> 
> >> There is no DLL at all in /my/otherdir (this is the very first place
> >> for Windows to look for DLL's, and i think that this cannot change).
> >> In /my/dir/bin, there is an updated version of a library also
> >> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
> >> 
> >> Does this mean that, under this change, cygstdc++-6.dll will be found
> >> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
> >> observe personnally.
> >> 
> >> Also, i don't remember that the CWD has an impact on where DLL is found (apart
> >> from being in PATH, and apart from being the dir where the exe resides).
> >> 
> >> For a test i have commented out in cygheap.cc the line
> >> 'wcpncpy (installation_dir, ...' (and also the next one)
> >> and the old behaviour is now back.
> >> 
> >> It seems to me that this change is a regression. Could someone please argue?
> > 
> > Hmm.  It's hard to do the right thing here, I guess.  I can see how
> > this is a regression in your scenario.  OTOH, your scenario is not
> > stable.  The directories in $PATH are the last ones in the DLL search
> > order.  So, your scenario already wouldn't work if your CWD is /bin
> > (or /usr/bin).
> Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
> in a Makefile, as part of some 'make check'. I don't usually build
> from /usr/bin.

Sure.  I was just pointing out that it's not a 100% stable method, but
dependent on the system's DLL search order, your CWD, and the fact that
the application is not installed into {/usr}/bin.

> I was not aware that CWD was useful. IIUC, your change removes the lookup
> into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
> the first place? These people (or specification?) will not be OK now.

If applications do this:

  chdir("/path/of/DLLs");
  dlopen("some.dll");

it wouldn't work anymore.  It wouldn't work on Linux either, unless CWD
is in LD_LIBRARY_PATH or the default search path.  This would work,
though:

  chdir("/path/of/DLLs");
  dlopen("/path/of/DLLs/some.dll");

Unfortunately the same doesn't work if the application calls execve
instead of dlopen because we can't add our LD_LIBRARY_PATH magic
there.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20141024/5984d45a/attachment.sig>