On Oct 16 23:51, Christian Franke wrote:
Corinna Vinschen wrote:
...
I implemented this in the latest snapshot. It calls SetDllDirectory
on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with
LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed.
For some reason,
On Oct 17 11:10, Corinna Vinschen wrote:
On Oct 16 23:51, Christian Franke wrote:
Corinna Vinschen wrote:
...
I implemented this in the latest snapshot. It calls SetDllDirectory
on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with
Corinna Vinschen wrote:
On Oct 17 11:10, Corinna Vinschen wrote:
On Oct 16 23:51, Christian Franke wrote:
Corinna Vinschen wrote:
...
I implemented this in the latest snapshot. It calls SetDllDirectory
on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with
On Oct 17 19:56, Christian Franke wrote:
Corinna Vinschen wrote:
On Oct 17 11:10, Corinna Vinschen wrote:
On Oct 16 23:51, Christian Franke wrote:
Corinna Vinschen wrote:
...
I implemented this in the latest snapshot. It calls SetDllDirectory
on Cygwin's /bin, and dlopen addiotnally tries
On Fri, Oct 17, 2014 at 8:20 PM, Corinna Vinschen wrote:
On Oct 17 19:56, Christian Franke wrote:
Now works.
cygwin_patches_for_postfix_count++; postfix_patches_for_cygwin_count--; :-)
You seem to like the idea... ;)
Of course. He has to deal with postfix, _you_ have to deal with Cygwin.
Corinna Vinschen wrote:
...
I implemented this in the latest snapshot. It calls SetDllDirectory
on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with
LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed.
For some reason, the SetDllDirectory() call has no effect for
On Oct 10 17:39, Corinna Vinschen wrote:
On Oct 10 14:13, Arjen Markus wrote:
2014-10-10 13:22 GMT+02:00 tednolan:
2014-10-10 13:24 GMT+02:00 Jan Nijtmans ...:
2014-10-10 12:34 GMT+02:00 Corinna Vinschen ...:
On Oct 9 11:46, tednolan.net wrote:
I'm pretty sure I've got some
On Oct 9 11:46, tedno...@bellsouth.net wrote:
In message 20141009162906.ga25...@calimero.vinschen.deyou write:
Any other idea what *might* be broken if we remove CWD from the
DLL search path?
Corinna
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the
2014-10-10 12:34 GMT+02:00 Corinna Vinschen corinna-cyg...@cygwin.com:
On Oct 9 11:46, tedno...@bellsouth.net wrote:
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the directory with the extension dlls, load the extension and then
change back to where ever they
This might the way the pkgIndex.tcl file for this particular extension
has been implemented, but like Jan says, that is not the Tcl way.
Here is a sample that illustrates the more acceptable procedure:
# Tcl package index file, version 1.0
if {![package vsatisfies [package provide Tcl] 8.6]}
In message CAMCbSMrar1Zu4p6gN=gc8-xqe-8rutmp3er0ujen--chkzc...@mail.gmail.com
you write:
This might the way the pkgIndex.tcl file for this particular extension
has been implemented, but like Jan says, that is not the Tcl way.
Here is a sample that illustrates the more acceptable procedure:
# Tcl
Right, that makes sense. There is indeed no way for the package
manager to handle that scenario without external help, such as a PATH
variable that includes the various directories these extra DLLs reside
in.
Regards,
Arjen
2014-10-10 13:22 GMT+02:00 tedno...@bellsouth.net:
In message
On Oct 10 14:13, Arjen Markus wrote:
2014-10-10 13:22 GMT+02:00 tednolan:
2014-10-10 13:24 GMT+02:00 Jan Nijtmans ...:
2014-10-10 12:34 GMT+02:00 Corinna Vinschen ...:
On Oct 9 11:46, tednolan.net wrote:
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the
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
On 10/09/2014 04:03 AM, Corinna Vinschen wrote:
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
On Oct 9 08:25, Eric Blake wrote:
On 10/09/2014 04:03 AM, Corinna Vinschen wrote:
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:
In message 20141009162906.ga25...@calimero.vinschen.deyou write:
Any other idea what *might* be broken if we remove CWD from the
DLL search path?
Corinna
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the directory with the extension dlls, load the extension and
On Sep 15 16:35, Christian Franke wrote:
Peter Rosin wrote:
On 2014-09-13 12:00, Christian Franke wrote:
Note that setting PATH=/bin on Cygwin does not fix the security problem in
the DLL search order. Even with SafeDllSearchMode enabled, the current
directory is always checked before PATH.
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
On 2014-09-13 12:00, Christian Franke wrote:
Eric Blake wrote:
(by passing an actual safe path, and NOT by completely unsetting PATH).
Disagree. The postfix master(8) spawns all of its daemons with PATH unset.
This IMO does not violate POSIX.
Note that setting PATH=/bin on Cygwin does
(sorry for replying to self)
On 2014-09-15 09:44, Peter Rosin wrote:
Also, SetDllDirectory will kill all attempts to run 32-bit
Cygwin programs from 64-bit Cygwin (and vice versa).
At least I think so.
Cheers,
Peter
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Peter Rosin wrote:
On 2014-09-13 12:00, Christian Franke wrote:
Note that setting PATH=/bin on Cygwin does not fix the security problem in the DLL search
order. Even with SafeDllSearchMode enabled, the current directory is always
checked before PATH. Running some Cygwin program from
On Fri, Sep 12, 2014 at 9:33 PM, Eric Blake wrote:
On 09/12/2014 11:02 AM, Christian Franke wrote:
(snip)
int main()
{
unsetenv(PATH);
This is undefined behavior, per POSIX. POSIX recommends that you always
leave PATH defined to at least a bare minimum of the results of
Eric Blake wrote:
On 09/12/2014 05:03 PM, Eric Blake wrote:
On 09/12/2014 04:50 PM, Christian Franke wrote:
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with
If PATH variable is unset or does not contain /bin or /usr/bin,
exec(/not_bin/program, ...) fails because cygwin DLLs could not be loaded.
This affects postfix which cleans the environment to the bare minimum
for security reasons.
(fortunately there is an easy workaround, so this does not
On 09/12/2014 11:02 AM, Christian Franke wrote:
If PATH variable is unset or does not contain /bin or /usr/bin,
exec(/not_bin/program, ...) fails because cygwin DLLs could not be
loaded.
This affects postfix which cleans the environment to the bare minimum
for security reasons.
Eric Blake wrote:
On 09/12/2014 11:02 AM, Christian Franke wrote:
If PATH variable is unset or does not contain /bin or /usr/bin,
exec(/not_bin/program, ...) fails because cygwin DLLs could not be
loaded.
This affects postfix which cleans the environment to the bare minimum
for security
Greetings, Christian Franke!
Enabling the SetDllDirectory() Win32 call fixes the problem.
Would possibly make sense to add this call to cygwin1.dll.
That said, just because POSIX has already given us the
get-out-of-jail-free card doesn't mean that we can't be nice and improve
cygwin1.dll to
On 09/12/2014 02:15 PM, Christian Franke wrote:
unsetenv(PATH);
This is undefined behavior, per POSIX. POSIX recommends that you always
leave PATH defined to at least a bare minimum of the results of
confstr(_CS_PATH, ...); it also states that implementations are free to
do what they want
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with full paths, unsetting $PATH does not improve
security in any way,
Of course. But postfix could be configured to
On 09/12/2014 04:50 PM, Christian Franke wrote:
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with full paths, unsetting $PATH does not
improve
security in any
On 09/12/2014 05:03 PM, Eric Blake wrote:
On 09/12/2014 04:50 PM, Christian Franke wrote:
Andrey Repin wrote:
Hmm... is postfix actually broken?
Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
absolute path names.
If all exec() calls are made with full paths,
On Fri, Sep 12, 2014 at 6:24 PM, Eric Blake ebl...@redhat.com wrote:
On 09/12/2014 02:15 PM, Christian Franke wrote:
unsetenv(PATH);
This is undefined behavior, per POSIX. POSIX recommends that you always
leave PATH defined to at least a bare minimum of the results of
confstr(_CS_PATH,
33 matches
Mail list logo
