Re: lt_dlerror changes

[Charles Wilson]

On 6/18/2010 2:32 PM, Bob Friesenhahn wrote:

>> The real problem is there actually IS a file named /usr/bin/last, but
>> because that name does not match exactly "last", last_open() reports
>> what it considers a generic error.
> 
> I seem to be backlogged by the flurry of email, but hopefully you guys
> will get this figured out.  I would be astonished if Windows
> LoadLibrary() is not willing to load a Windows executable file similar
> to the way it loads a DLL.

Well, there IS one difference AFAIK: if a file exists named
"C:\temp\bob.dll" and I try to LoadLibrary "C:\temp\bob", it will
succeed because LoadLibrary will automatically append a .dll (unless you
put a trailing '.' on it):

http://msdn.microsoft.com/en-us/library/ms684175%28VS.85%29.aspx
> If no file name extension is specified in the lpFileName parameter,
> the default library extension .dll is appended. However, the file name
> string can include a trailing point character (.) to indicate that the
> module name has no extension. When no path is specified, the function
> searches for loaded modules whose base name matches the base name of the
> module to be loaded. If the name matches, the load succeeds. Otherwise,
> the function searches for the file.

But it won't automatically append ".exe".

In this case, we have a disagreement betweeen Windows and cygwin --
cygwin's access() function (and stat, and fopen, and lots of other
things) will automatically check for "bob.exe" when asked about "bob".

So, libltdl thinks "/usr/bin/last" exists, because
C:\cygwin\bin\last.exe does. However, LoadLibrary, when passed the
dos-ified version of "/usr/bin/last" -- that is, "C:\cygwin\bin\last"
with no extension -- fails, because LoadLibrary doesn't try to append
".exe" like cygwin's file access functions do.

> If so, this raises security implications
> that we want to avoid.

I don't think so.

--
Chuck