On Mon Mar 27 21:41:10 2023 +0000, Zebediah Figura wrote:
This would break if xattrs can't be stored while the filesystem itself
is (mounted) read-only. I would assume we can't set xattrs if the filesystem is read-only?
The short gist of it is that the read-only attribute should always be
allowed to be changed or inspected, even on unix filesystems without xattrs. "stop stripping POSIX write access *if* we can store with xattr" should work. Not to argue against having a fallback, but what filesystems don't support xattrs? There's FAT, but we could easily add support for FAT_IOCTL_SET_ATTRIBUTES.
Ok I've spent some time thinking about this.
1. 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.
2. 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.
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 3-step process: chmod, open, fchmod. i.e. the path has to be resolved twice leaving the door open to TOCTOU race conditions. However, at least this is happening in server, so the other wine threads are implicitly excluded.
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?
3. 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`.