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 C
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 d
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
LoadLibraryEx(LOAD_WITH
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
> > >LoadLibraryEx(LOAD_WITH_AL
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
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 exe
On Oct 10 17:39, Corinna Vinschen wrote:
> On Oct 10 14:13, Arjen Markus wrote:
> > 2014-10-10 13:22 GMT+02:00 :
> > >>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
On Oct 10 14:13, Arjen Markus wrote:
> 2014-10-10 13:22 GMT+02:00 :
> >>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
> >
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 :
> In message
>
> you write:
>>This mig
In message
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 package index file, version 1.0
>
>if {![package vsatisfies
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]} {re
2014-10-10 12:34 GMT+02:00 Corinna Vinschen :
> 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 were.
>
> Hmm. If so,
On Oct 9 11:46, tedno...@bellsouth.net wrote:
> In message <20141009162906.ga25...@calimero.vinschen.de>you 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 th
In message <20141009162906.ga25...@calimero.vinschen.de>you 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 extensio
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 pa
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 d
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
> >
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 searc
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
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 /usr/sbi
(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:
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 Cygw
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 ful
On Fri, Sep 12, 2014 at 6:24 PM, Eric Blake 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, ...)
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 ful
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
>> s
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 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 wh
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
>> cygw
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 reaso
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.
> (fo
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 blo
33 matches
Mail list logo
