On Mon, 27 Sep 2010, Craig Barkhouse wrote:
Benjamin R. Haskell wrote:
Gist is that the Windows DLL loading process searches the current
directory, unless specifically instructed not to. (Idiotic.)
It's not idiotic that the current directory would be somewhere in the search
order.
Yes it is. From a security standpoint, it allows bugs like the one in
question. For other reasons, google:
DLL search current directory
or
dot in PATH
Note that the search order also includes searching the whole PATH. On
Windows, the PATH implicitly includes the current directory -- this is
the reason you don't have to type .\vim.exe to run Vim if it's in the
current directory, even without explicitly adding . to your PATH.
Yes, and I still think that's a bad idea.
If you want to be able to execute something without typing a relative
path, it should be in your PATH list. If you want '.' in your PATH, go
for it (I don't.). Having an implicit entry in that list is idiotic,
regardless of its placement.
At least it hasn't fronted the current directory by default for a
while. (Prior to XP SP2 default search order started with the
Current dir and ended with the system dirs.)
The current directory has never been the first location in the search
order. The first location has always been the application directory.
This is pretty much required because you need to be able to ship
applications that use their own DLLs without the possibility of
colliding with other similarly named DLLs elsewhere on the system. If
Vim installs its own libintl.dll, which it does, then there's no
security issue.
What changed with XP SP2 was that the current directory was moved from
before the Windows directories to after the Windows directories. Now
it's adjacent in the search order to the rest of PATH, which makes
much more sense since as noted above the current directory is
implicitly considered to be part of PATH. Link:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx. It's
easy to see that this change only matters for standard Windows DLLs.
For any third party DLL, e.g. libintl.dll, it won't be found in the
Windows directories so the effective search order is always simply 1)
application directory; 2) current directory; 3) rest of PATH.
Ah. Yes. Thanks for clearing that up. Didn't follow your link
immediately, but was about to send that page to say, "Yeah, my bad."
after finding it as the top result for:
Win32 DLL search order
It does explain it well. Still, it's a pity that Windows has such a
long history of requiring applications to ship their own versions of all
the libraries they use. (Even more frustrating with Java apps (which
ship entire JRE's).)
Back to the problem, though: there's quite obviously some utility to be
gained from having the application's launch directory in the search path
(It's where the DLL's you likely want to use are kept). But what's the
use-case for having the current directory searched?
Even with DLL-searching (as opposed to PATH-searching), I could see
reasons to want to override the application directory (testing,
instrumentation). So I still disagree with the design decision to have
it as an implicit entry.
It amuses me that the search path includes:
"""
The 16-bit system directory. There is no function that obtains the path
of this directory, but it is searched.
"""
Regardless, thanks for clearing up my application vs. current directory
misunderstanding. That coupled with Windows apps shipping their own
DLL's for all libraries makes this a much less scary situation. (E.g.
for Vim, this seems to be a non-issue, since it ships its own
libintl.dll.)
--
Best,
Ben
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
