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
