[Bug 39647] New: Broken FILE_EXECUTE mapping

https://bugs.winehq.org/show_bug.cgi?id=39647

Bug ID: 39647
           Summary: Broken FILE_EXECUTE mapping
           Product: Wine
           Version: 1.8-rc1
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Some Windows applications (Office 2010 for instance) save the files with owner
and world ACLs that grant FILE_READ_DATA, FILE_WRITE_DATA and FILE_EXECUTE
permissions. FILE_EXECUTE causes the Unix execute permissions to be set on the
file. Already this is wrong: these are documents, not Unix binaries or scripts.

But it also causes trouble to uses in that this causes some Unix file managers
to try to execute the file when the user double-clicks on it, instead of
looking for an application that can open it. Thus the user gets a confusing
'cannot execute' error and must go through the 'Open with' contextual menu to
actually be able to edit their documents.

The thing is that, as far as I can tell, this FILE_EXECUTE to +x permission
mapping is bogus. From the MSDN:

http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%29.aspx

FILE_EXECUTE
   Data can be read into memory from the file using system paging I/O.
   This flag is irrelevant for device and intermediate drivers.

So if the MSDN is right FILE_EXECUTE has nothing with making it possible to
execute the file and thus the maping makes no sense.

This issue happens in server/file.c in file_access_to_mode() and sd_to_mode().

trace:file:CreateFileW L"C:\users\crossover\My Documents\aFoo1.docx"
FILE_SHARE_READ FILE_SHARE_WRITE FILE_SHARE_DELETE  creation 3 attributes
0x2000000
trace:ntdll:FILE_CreateFile handle=0x97eb41c access=000c0000
name=L"\??\C:\users\crossover\My Documents\aFoo1.docx" objattr=00000040
root=(nil) sec=(nil) io=0x97eb40c alloc_size=(nil) attr=00000000
sharing=00000007 disp=1 options=00004020 ea=(nil).0x00000000
trace:file:CreateFileW returning 0x41c
trace:ntdll:NtSetSecurityObject 0x41c 0x00000006 0x97eb534
trace:ntdll:RtlGetControlSecurityDescriptor (0x97eb534,0x97eb41c,0x97eb408)
trace:ntdll:RtlLengthSid sid=0x97eb564
trace:ntdll:RtlGetDaclSecurityDescriptor
(0x97eb534,0x97eb41e,0x97eb418,0x97eb41f)
sd_to_mode:531 owner+current Mask=1f01ff new_mode= 770
sd_to_mode:525 world Mask=1200a9 new_mode= 775

There's a concern that some applications might set the flag and check it later.
There is no known case though. The closest is that Office 2010 does read the
ACL of the files it opens and then writes it to the file it saves but it
obviously has no trouble with files that are not marked +x.
Still, because of this concern this may be a good candidate for Staging.