On Tue, Jan 14, 2025 at 10:53:50PM +0100, Pali Rohár wrote: > On Tuesday 14 January 2025 16:44:55 Chuck Lever wrote: > > On 1/14/25 4:10 PM, Pali Rohár wrote: > > > On Saturday 04 January 2025 10:30:26 Chuck Lever wrote: > > > > On 1/4/25 3:52 AM, Christian Brauner wrote: > > > > > On Thu, Jan 02, 2025 at 10:52:51AM -0500, Chuck Lever wrote: > > > > > > On 1/2/25 9:37 AM, Jan Kara wrote: > > > > > > > Hello! > > > > > > > > > > > > > > On Fri 27-12-24 13:15:08, Pali Rohár wrote: > > > > > > > > Few months ago I discussed with Steve that Linux SMB client has some > > > > > > > > problems during removal of directory which has read-only attribute set. > > > > > > > > > > > > > > > > I was looking what exactly the read-only windows attribute means, how it > > > > > > > > is interpreted by Linux and in my opinion it is wrongly used in Linux at > > > > > > > > all. > > > > > > > > > > > > > > > > Windows filesystems NTFS and ReFS, and also exported over SMB supports > > > > > > > > two ways how to present some file or directory as read-only. First > > > > > > > > option is by setting ACL permissions (for particular or all users) to > > > > > > > > GENERIC_READ-only. Second option is by setting the read-only attribute. > > > > > > > > Second option is available also for (ex)FAT filesystems (first option via > > > > > > > > ACL is not possible on (ex)FAT as it does not have ACLs). > > > > > > > > > > > > > > > > First option (ACL) is basically same as clearing all "w" bits in mode > > > > > > > > and ACL (if present) on Linux. It enforces security permission behavior. > > > > > > > > Note that if the parent directory grants for user delete child > > > > > > > > permission then the file can be deleted. This behavior is same for Linux > > > > > > > > and Windows (on Windows there is separate ACL for delete child, on Linux > > > > > > > > it is part of directory's write permission). > > > > > > > > > > > > > > > > Second option (Windows read-only attribute) means that the file/dir > > > > > > > > cannot be opened in write mode, its metadata attribute cannot be changed > > > > > > > > and the file/dir cannot be deleted at all. But anybody who has > > > > > > > > WRITE_ATTRIBUTES ACL permission can clear this attribute and do whatever > > > > > > > > wants. > > > > > > > > > > > > > > I guess someone with more experience how to fuse together Windows & Linux > > > > > > > permission semantics should chime in here but here are my thoughts. > > > > > > > > > > > > > > > Linux filesystems has similar thing to Windows read-only attribute > > > > > > > > (FILE_ATTRIBUTE_READONLY). It is "immutable" bit (FS_IMMUTABLE_FL), > > > > > > > > which can be set by the "chattr" tool. Seems that the only difference > > > > > > > > between Windows read-only and Linux immutable is that on Linux only > > > > > > > > process with CAP_LINUX_IMMUTABLE can set or clear this bit. On Windows > > > > > > > > it can be anybody who has write ACL. > > > > > > > > > > > > > > > > Now I'm thinking, how should be Windows read-only bit interpreted by > > > > > > > > Linux filesystems drivers (FAT, exFAT, NTFS, SMB)? I see few options: > > > > > > > > > > > > > > > > 0) Simply ignored. Disadvantage is that over network fs, user would not > > > > > > > > be able to do modify or delete such file, even as root. > > > > > > > > > > > > > > > > 1) Smartly ignored. Meaning that for local fs, it is ignored and for > > > > > > > > network fs it has to be cleared before any write/modify/delete > > > > > > > > operation. > > > > > > > > > > > > > > > > 2) Translated to Linux mode/ACL. So the user has some ability to see it > > > > > > > > or change it via chmod. Disadvantage is that it mix ACL/mode. > > > > > > > > > > > > > > So this option looks sensible to me. We clear all write permissions in > > > > > > > file's mode / ACL. For reading that is fully compatible, for mode > > > > > > > modifications it gets a bit messy (probably I'd suggest to just clear > > > > > > > FILE_ATTRIBUTE_READONLY on modification) but kind of close. > > > > > > > > > > > > IMO Linux should store the Windows-specific attribute information but > > > > > > otherwise ignore it. Modifying ACLs based seems like a road to despair. > > > > > > Plus there's no ACL representation for OFFLINE and some of the other > > > > > > items that we'd like to be able to support. > > > > > > > > > > > > > > > > > > If I were king-for-a-day (tm) I would create a system xattr namespace > > > > > > just for these items, and provide a VFS/statx API for consumers like > > > > > > Samba, ksmbd, and knfsd to set and get these items. Each local > > > > > > filesystem can then implement storage with either the xattr or (eg, > > > > > > ntfs) can store them directly. > > > > > > > > > > Introducing a new xattr namespace for this wouldn't be a problem imho. > > > > > Why would this need a new statx() extension though? Wouldn't the regular > > > > > xattr apis to set and get xattrs be enough? > > > > > > > > My thought was to have a consistent API to access these attributes, and > > > > let the filesystem implementers decide how they want to store them. The > > > > Linux implementation of ntfs, for example, probably wants to store these > > > > on disk in a way that is compatible with the Windows implementation of > > > > NTFS. > > > > > > > > A common API would mean that consumers (like NFSD) wouldn't have to know > > > > those details. > > > > > > > > > > > > -- > > > > Chuck Lever > > > > > > So, what about introducing new xattrs for every attribute with this pattern? > > > > > > system.attr.readonly > > > system.attr.hidden > > > system.attr.system > > > system.attr.archive > > > system.attr.temporary > > > system.attr.offline > > > system.attr.not_content_indexed > > > > Yes, all of them could be stored as xattrs for file systems that do > > not already support these attributes. > > > > But I think we don't want to expose them directly to users, however. > > Some file systems, like NTFS, might want to store these on-disk in a way > > that is compatible with Windows. > > > > So I think we want to create statx APIs for consumers like user space > > and knfsd, who do not care to know the specifics of how this information > > is stored by each file system. > > > > The xattrs would be for file systems that do not already have a way to > > represent this information in their on-disk format. > > > > > > > All those attributes can be set by user, I took names from SMB, which > > > matches NTFS and which subsets are used by other filesystems like FAT, > > > exFAT, NFS4, UDF, ... > > > > > > Every xattr would be in system.attr namespace and would contain either > > > value 0 or 1 based on that fact if is set or unset. If the filesystem > > > does not support particular attribute then xattr get/set would return > > > error that it does not exist. > > > > Or, if the xattr exists, then that means the equivalent Windows > > attribute is asserted; and if it does not, the equivalent Windows > > attribute is clear. But again, I think each file system should be > > able to choose how they implement these, and that implementation is > > then hidden by statx. > > > > > > > This would be possible to use by existing userspace getfattr/setfattr > > > tools and also by knfsd/ksmbd via accessing xattrs directly. > > > > > > -- > > Chuck Lever > > With this xattr scheme I mean that API would be xattr between fs and > vfs/userspace/knfsd/smbd. So NTFS would take that xattr request and > translate it to its own NTFS attributes. Other non-windows fs stores > them as xattrs. > > I think that you understood it quite differently as I thought because > you are proposing statx() API for fetching them. I thought that they > would be exported via getxattr()/setxattr(). > > This is also a good idea, just would need to write new userspace tools > for setting and gettting... And there is still one important thing. How > to modify those attribute? Because statx() is GET-only API. statx/FS_IOC_FSGETXATTR to retrieve and FS_IOC_FSSETXATTR to set? Last time this came up hch said no to random magic xattrs that every filesystem then has to filter. --D
