https://bugs.winehq.org/show_bug.cgi?id=50771
--- Comment #5 from Joel Holdsworth joel@airwebreathe.org.uk --- https://github.com/wine-staging/wine-staging/blob/master/patches/server-File...
That patch looks extremely promising. My only comment on it is that I don't think FILE_WRITE_ATTRIBUTES (and perhaps FILE_WRITE_EA?) should be in the FILE_UNIX_WRITE_ACCESS in any case.
If the application requests to write a file's attributes, that is no reason to attempt to open the file data. This patch relies on open() failing but I wonder if FILE_WRITE_ATTRIBUTES should be handled differently in the first place. Something like:
1. open() the file if the application requested FILE_READ_DATA, FILE_WRITE_DATA or FILE_APPEND_DATA 2. If the application requested FILE_WRITE_ATTRIBUTES, FILE_UNIX_READ_ACCESS or DELETE, then stat() the file. Open it with whatever permissions are avaiable. 3. If the file is non-read and non-write, then temporarily chmod() and open().
On Linux, there would be a benefit to handling #2 and #3 through a seperate code path using O_PATH, because it would remove the vulnerability to TOCTOU (time-of-check to time-of-use) issues.
I might find time to attempt these changes, but what is the policy for evolving other people's patches? Is there a label I can put on for dual authorship? Would I make my changes as a seperate patch? Or just rewrite the patch, and submit it as my own work?