At 06:40 PM 8/17/99 +0100, Kenn Humborg wrote: >> >While testing IIS security, I was able to locate an old flaw which is >> >still present in many server services on Win32. The problem deals >> >with a compatibility issue with the old Win16/DOS file naming system >> >known as the 8.3 naming system. >> >> One well-known workaround for this issue that will take care of this >> problem, regardless of the server software, is to disable 8.3 filenames. >Does this break the GetShortPathName function? This converts >long file names in the 8.3 equivalent. It seems like it could cause it to fail under some circumstances - the API doc says: "When an application calls this function and specifies a path on a volume that does not support 8.3 aliases, the function fails with ERROR_INVALID_PARAMETER if the path is longer than 67 bytes." >The catch is that Microsoft recommend using the 8.3 name when >registering COM servers (due to a bug in CreateProcess when there >is a space in the server's directory path or file name). So you may >not be able to register any COM servers on this partition (which may >not be a bad thing... :-) For one thing, you'd normally stick a COM server up under %systemroot%, or you could put it anywhere else on the file system outside of the web server. I'm not aware of any bug that triggers in COM with spaces (are you sure it affects NT?) I also just read a lot of info on COM, and it didn't mention that. I'm also almost certain (though I ought to doublecheck) that CreateProcess() isn't foiled by spaces (else 'c:\program files\' would cause mayhem). Lastly, I do know that when the 8.3 IIS bug first hit quite a while back, this was the recommended workaround, and I don't recall this issue coming up. So to sum up, I can't guarantee it won't be an issue, but I'd like it if someone could confirm one way or another. Has anyone set this flag and had actual reproducible problems? David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:57:21 PDT