http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #3 from Forester pbronline-wine@yahoo.co.uk 2008-08-21 15:13:02 --- The console log for the install under 0.9.36 reads
Log file name:c:\windows\Corel\Setup.log fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\My Documents") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\Start Menu") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\All Users\Start Menu") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\Desktop") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\Fonts") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\system32") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\Program Files") : returns fake SECURITY_DESCRIPTOR
Which ties in with what I've found using the wine debugger on the Wine 1.1.1 code base.
The installer routine that issues the message box signalling its refusal to go any further does some 19 checks after calling advapi::PrivilegeCheck. Nine fail, corresponding to the nine directories lists above. The nine checks are 'short circuited' when emulating Windows 98.
What 'fails' is a call to advapi::GetSecurityDescriptorDacl (yes Dacl, not Sacl). It returns lpbDaclPresent as false. This is not surprising since the security descriptor passed in is only 0x14 bytes big, which is the bare minimum, and so there can't be a dacl present.
Earlier, the installer calls advapi::GetFileSecurityA in order to find out how much memory to allocate for the security descriptor. This routine returns 0x14 so the later fail is a certainty.
advapi::GetFileSecurityA calls ntdll::NtQuerySecurityObject. In Wine 0.9.37 a fixme claims this is a stub. In the Wine 1.1.1 code base, the implementation looks complete, assuming the potential infinite loop is deliberate aping of Windows behaviour.
ntdll::NtQuerySecurityObject calls the Wine server. An fprintf added to handle.c::DECL_HANDLER(get_security_object) confirms that the object that corresponds to the handle for the directory has no security descriptor. That is sd->obj is 0.
I've gone as far with this on my own as I think I can.