Re: Suggestion for LoadLibrary in windows

[Mike Pall <mikelu-0612@...>]

Hi,

Cloud Wu wrote:
> I think using the "!" to  instead of "the path of the directory of the
> executable file of the current process" is no use today. (IMHO)

But we want to be able to exactly specify the Lua module search
path _and_ avoid loading DLLs from the Windows default search
path by accident (no Lua module should ever be installed there).

E.g. the first lookup of "?.dll" might return a system DLL which
stops the search. All remaining Lua module path elements would be
ignored. Thus we cannot drop the current meaning of "!".

> So, let the "!" replaced by the current path is better. (IMHO)

As has been noted before the concept of a current directory is a
bit fuzzy in Windows (and non-existent in WinCE). The idea to be
able to use ".\\?.dll" to load relative to the current directory
_and_ avoid the default search apparently doesn't always work.
I've searched for more hints but found no definitive answer.

But I've found several postings in various forums which indicate
problems when you feed relative paths to LoadLibrary. Seems the
exact behaviour depends on the OS version and service level. The
general recommendation was to use GetFullPathName() and always
pass absolute paths to LoadLibrary() [possible FIX #1].


I've noted quite a few security related postings during my
search. Loading anything relative to the current directory is an
accident waiting to happen. It's far too easy for someone to mess
up their system or to fall prey to malicious code injection. Note
that even a seemingly innocent file open dialog may change the
current directory ...

I realize that it's convenient for testing to be able to just
type 'lua -l foo ...' or require("foo") and load 'foo.dll',
'foo.so' or 'foo.lua' from the current directory. But IMHO this
leads to unpredictable and possibly dangerous behaviour for
applications released to a wider public.

Sure, you can blame this on the developer who didn't edit
luaconf.h before releasing a security critical application. But
it might be better if we play it conservative.

Since we really, really want to avoid a later public outcry about
Lua being "unsafe" or a "security risk" I suggest to remove the
current directory from the search path for require(). Both on
Windows and on POSIX platforms [possible FIX #2].

This also avoids the above problem of course. But the main
consequence is that you _must_ install modules to be loaded with
require() into a directory in the Lua module search path. Anyone
can override the behaviour by setting LUA_PATH or LUA_CPATH or
editing luaconf.h. But he/she does so at his/her own risk (e.g.
only during development).

Note: the current directory still works for scripts loaded with
dofile("foo.lua") or on the command line with 'lua foo.lua'.

Bye,
     Mike