PHP on Windows should not rely on PATH for loading its DLL dependencies

[vrubleg]

There is a longstanding issue with mod_php for Apache when PHP extensions can't be loaded without adding PHP directory to PATH because they rely on some libraries which are in the root PHP directory, and the OS looks for them in the root Apache directory by default. Also, it causes an issue when a user has a few versions of PHP installed (with separate copies of Apache), one of them is in the PATH, and all the others try to load their extensions from that directory in PATH, and fail.

It is possible to resolve this issue by adding the directory of php_mod dll into the list of dll directories of current process. You should use the AddDllDirectory (supported in Windows 7+ since 2011) to specify additional DLL search path. It could be made in the DllMain of the php8apache2_4.dll like this:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <shlwapi.h>

BOOL APIENTRY DllMain(HMODULE hmodule, DWORD dwreason, LPVOID lpreserved)
{
	static DLL_DIRECTORY_COOKIE dircookie = nullptr;

	switch (dwreason)
	{
	case DLL_PROCESS_ATTACH:

		SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_DEFAULT_DIRS);

		TCHAR path[MAX_PATH];
		if (GetModuleFileName(hmodule, path, MAX_PATH))
		{
			PathRemoveFileSpec(path);
			dircookie = AddDllDirectory(path);
		}

		break;

	case DLL_PROCESS_DETACH:

		if (dircookie)
		{
			RemoveDllDirectory(dircookie);
			dircookie = nullptr;
		}

		break;
	}

	return TRUE;
}

Another option would be using AddDllDirectory during early initialization and passing LOAD_LIBRARY_SEARCH_DEFAULT_DIRS to every LoadLibrary call.

It makes sense to implement this for better security because a lot of unexpected things can be in PATH and load instead of what was expected. It will also resolve issues like #10076. This issue was already discussed in the mailing list and Christoph M. Becker agreed that it is OK to include such change.

[mvorisek]

I agree, related with #9893

[cmb69]

I agree, related with #9893

Not necessarily. It depends on the implementation; the suggestion above would only affect apache2handler while #9893 was about NTS builds.

[cmb69]

A recurring topic! In the meantime I've forgot about this ticket, and submitted PR #16958. That uses SetDllDirectory() what may or may not be "better" than AddDllDirectory(). Either way, that would not solve all issues (DLLs in the Apache folder are still looked up first), and it doesn't feel clean that an extension module sets/adds a DLL search path, thus affecting all other extensions (e.g. might interfere with mod_perl etc.) Unfortunately, Apache doesn't over this functionality; only LoadLibrary is supported, what requires to specify each library individually (although that might be good idea for stability and security reasons anyway, but is particularly inconvenient for development environments).

Also, it causes an issue when a user has a few versions of PHP installed (with separate copies of Apache), one of them is in the PATH, and all the others try to load their extensions from that directory in PATH, and fail.

It's even worse than that, since DLLs are searched in the PATH very late, and any DLL in the system folder takes precedence.

Anyhow, I'll try to have a look at #16958 again wrt using AddDllDirectory() (feels less intrusive).

[vrubleg]

AddDllDirectory is definitely a bit less intrusive and allows a few modules use the same approach at the same time.