Skip site navigation (1) Skip section navigation (2)

Re: Novice Guide to Windows Compile How to

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Novice Guide to Windows Compile How to
Date: 2004-05-13 14:51:01
Message-ID: 40A38B55.4070604@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Magnus Hagander wrote:

>>
>>http://support.microsoft.com/default.aspx?scid=kb;en-us;815065 says:
>>
>>
>>Windows then searches for the DLLs in the following sequence:
>>. The directory where the executable program for the current 
>>process is located.
>>. The current directory.
>>. The Windows system directory. (The GetSystemDirectory 
>>function gets the path of the Windows system directory.) . 
>>The Windows directory. (The GetWindowsDirectory function gets 
>>the path of the Windows directory.) . The directories that 
>>are listed in the PATH environment variable.
>>    
>>
>
>>From what I can tell, this article is not valid for XP SP1+ and Server
>2003 (if you look at the article, you'll see that it specifically
>excludes Windows Server 2003). Current Directory is moved way down on
>the list. But it could be that "application directory" is treated
>different than "current directory". Look at the text in this article:
>See
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/
>html/secure06122003.asp
>
>under the header "DLL Search Order Has Changed".
>It says it loads from the system directories *first*. Now, if there is
>no DLL in the system directories, then it will pick it up from the app
>dir. But if there is a different version in the system dirs, it will use
>that one (and break).
>
>
>But then it really shouldn't affect this. It's still loaded before
>what's in the PATH. What it says is we should stay away from stuffing
>things in the windows/system directories. That will create problems in
>the future.
>
>  
>

As usual their documentation just sucks.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/load_time_dynamic_linking.asp 

appears to suggest, although it is not explicit, that the changed 
behaviour affects only the location of current directory, not 
application directory, in the search order.

Can anyone clarify what the *actual* behaviour is?

(Their supposed justification for the change seems to me to be a bit 
dubious too, at least if it applies to the app directory: "The reason 
this change was made was to mitigate some kinds of trojaning attacks. An 
attacker may be able to sneak a bad DLL into your application directory 
or a directory that has files associated with your application. The DLL 
search order change removes this attack vector." If they can sneak in a 
DLL why can't they also sneak in a .exe? OTOH lowering current directory 
in the search order makes more sense.)

cheers

andrew



In response to

pgsql-hackers-win32 by date

Next:From: Andrew DunstanDate: 2004-05-13 16:19:12
Subject: Re: mingw configure failure detection
Previous:From: Magnus HaganderDate: 2004-05-13 13:32:34
Subject: Re: Novice Guide to Windows Compile How to

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group