Ok I've spent some time thinking about this.
As I mentioend previously I think we should make use of other storage methods in addition:
- Samba v4 User xattrs
- Linux NTFS DOS Attribute System xattrs
- Linux `FAT_IOCTL_SET_ATTRIBUTES`
- Perhaps BSD/MacOS `st_flags` `UF_IMMUTABLE`, though this presents a less severe version of the POSIX access flags problme.
I have some experimental patches lined up to cover these things.
I agree with you that we have a big problem with using POSIX file permissions to store the `READONLY` DOS attribute.
We have made a comittment to storing DOS attributes in User xattrs. In this case we need to be able to call fsetxattr on any file that is opened with `FILE_WRITE_ATTRIBUTES`, which requires that the fd would be openned with write access.
Yeah, although maybe it's not a *big* problem? I don't remember the Cygwin code, but if this patch set works, then it doesn't actually need NtSetAttributesFile() to succeed, and there's no other known users of FILE_WRITE_ATTRIBUTES without FILE_WRITE_DATA, which is a weird and corner-case-ish thing to do anyway.
I thought about delayed approaches i.e. increasing access permissions temporarily if fsetxattr fails with `EACCESS`, but this won't work. We cannot change the access of an existing fd. fcntl doesn't allow us to do that, and we cannot reopen the file, because we won't know its path.
So as I see it, there are two possible approaches:
a) As per the wine-staging patch, temporarily chmod the file in server when opening the fd so as to get a writable fd of an otherwise read-only file.
This would involve a 4-step process: `stat`, `chmod`, `open`, `fchmod`. i.e. the path has to be resolved three times leaving the door open to TOCTOU race conditions. However, at least this is happening in server, so the other wine threads are implicitly excluded.
I still really don't like this solution. TOCTOU bothers me less than that it just feels too much like a hack.
b) Stop using POSIX file permissions, and rely solely on Samba User xattrs, and other methods.
Out of the two, (a) seems more better to me, but I think either approach is quite reasonable. What do you think?
- Either one of these approaches supercedes my pigging-backing approach. As before, `FILE_READ_ATTRIBUTES` would require `O_RDONLY`. `FILE_WRITE_ATTRIBUTES` would require `O_WRONLY`. `FILE_READ_ATTRIBUTES|FILE_WRITE_ATTRIBUTES` would require `O_RDWR`.