Message-ID: <20250114215350.gkc2e2kcovj43hk7@pali>
Date: Tue, 14 Jan 2025 22:53:50 +0100
From: Pali Rohár <pali@...nel.org>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org, Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: Immutable vs read-only for Windows compatibility

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.

Powered by blists - more mailing lists