DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=uV8rCLZA34dQyF3UmfOMXgPsIndGEIxXTPNLy01Ac4GpRHHC37FBp
	ddsv8JH6ZqcjdaXtnCAgnE/W6LVluEYl752pzqFsL/zdpyqvvgA2pBI2QX+9ZIe8
	UWc0D2tUTQzyzIVrRsGHK3aJgRkc0UQ+irnWWbQjm9uLVASsvO8v50=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 24 Oct 2014 21:36:38 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: Christian Franke <Christian DOT Franke AT t-online DOT de>
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Message-ID: <20141024193638.GO20607@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com,	Christian Franke <Christian DOT Franke AT t-online DOT de>
References: <announce DOT 20141022092323 DOT GH32374 AT calimero DOT vinschen DOT de> <A0FD00D9-6DFB-4E3D-9FDE-44BC1CAAEEDC AT Denis-Excoffier DOT org> <20141024110209 DOT GJ20607 AT calimero DOT vinschen DOT de> <25D5C8B8-57B7-449C-95C6-CD9055816B6B AT Denis-Excoffier DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="KM+e2hnYAO+MCJ5e"
Content-Disposition: inline
In-Reply-To: <25D5C8B8-57B7-449C-95C6-CD9055816B6B@Denis-Excoffier.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

--KM+e2hnYAO+MCJ5e
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[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:
> >>>=20
> >>> - 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.
> >>=20
> >> I use
> >> PATH=3D/my/dir/bin:/usr/bin /my/otherdir/myprog
> >>=20
> >> 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).
> >>=20
> >> 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.
> >>=20
> >> Also, i don't remember that the CWD has an impact on where DLL is foun=
d (apart
> >> from being in PATH, and apart from being the dir where the exe resides=
).
> >>=20
> >> 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.
> >>=20
> >> It seems to me that this change is a regression. Could someone please =
argue?
> >=20
> > 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=3D/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.
>=20
> 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

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

--KM+e2hnYAO+MCJ5e
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUSqpGAAoJEPU2Bp2uRE+g854QAJZ/E/iKxsCUNLg3J9d6vt5Z
u6FqxhpGh1ImOoELVHLQybBFAAZMsnpL8sFpfL6DCZczI9HNbiKfCgOusZJXk/pO
4lSX1GXgE0qjB0VGH0DsuaVP9cHEn+ykgAUvdZVcF6eXiRCZKXiSycSXpexjh7lm
IZsAhwFvYT40TckWLxrffo7vFoVn0pZlAje7/y4LjZcrkc5lN9xkHo8CdzowH75N
FE7TqBPO2oQoG+0effIvZh2Zzii+ADfMl1O2T2EJvmBH1EhqzKMCHkZEHgf4BAM6
w4pLfmJ61LHiRXk1i+dVYOw96+mdil7lAoPmSqLd9zM1JU2orGktPPw1UGELI8hY
vk6Q2F2zdpmlzM6X/3LJls8OG2m34pi//OMOG2O15jdjTOQdIFrtSE8jrPB1Q2tK
00/OViios7g3car9qH9JNFpYPlUZQ7D9rxAnCI+rCbGbl3EnS2vR4piUk9qaqRui
iZuLALr/1uHLNW0bzzZiCVky+yhSCNKAaZB92mHtRbmnnfC8ELjMItcU5JuPWehU
oMKEuYA0fx0mRjbT+5wXlo+kjYXIDUWTzKrHYzG8zfYyepCfe+oG2ODri4JPgfe8
XimIfGOnZqU1mavK1Mox2og7uhVT0gz/GZuk4bKW/e0LBaqULTyImK/JTAs+WRAe
XFTdvyZSkh25v6ydwYk/
=xNB1
-----END PGP SIGNATURE-----

--KM+e2hnYAO+MCJ5e--