On Oct 8 19:15, Christian Franke wrote: > Corinna Vinschen wrote: > >On Sep 15 16:35, Christian Franke wrote: > >>... > >I'm somewhat reluctant to add a call to SetDllDirectory to the Cygwin > >DLL for two reasons. > > > >- Calling SetDllDirectory with an explicit dir doesn't just add this dir > > to the search path, it also removes the CWD from the search path. > > While I agree that this is a good thing from a security POV, can we be > > sure that this behaviour isn't needed somewhere, by somebody? > > > >- The fact that SetDllDirectory affects searching linked DLLs in calls > > to CreateProcess is undocumented. Per the original MSDN pages, > > SetDllDirectory affects calls to LoadLibrary and LoadLibraryEx, but > > not linked DLLs when starting a child process. The latter is only > > mentioned in a Community Addition: > > > > > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx > > > >Having said that, we can certainly test this, but I'm wondering > >if an upstream Cygwin patch might be ok. Something similar has been > >applied to the portable OpenSSH repository years ago, so there's > >precedent. > > We could leave this open for now. I already added an easy workaround to > postfix > (add PATH=/usr/bin to import/export_environment default settings).
Ok. Or... hmm. The fact that using SetDllDirectory disallows searching the CWD got me thinking twice. Security-wise it would really be the right thing to do. Usually DLLs are in defined search paths: - Application dir - Application defined dirs - System dirs So, what scenario would actually break by removing CWD from the search path? Running tests in an libtoolized project dir, perhaps? Is that a valid concern or did libtool already take care of this? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpKVQVCVm2PU.pgp
Description: PGP signature