Message-ID: <20250117173900.GN3557553@frogsfrogsfrogs>
Date: Fri, 17 Jan 2025 09:39:00 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: Pali Rohár <pali@...nel.org>,
	ronnie sahlberg <ronniesahlberg@...il.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	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 Fri, Jan 17, 2025 at 05:53:34PM +0100, Amir Goldstein wrote:
> On Wed, Jan 15, 2025 at 12:59 AM Darrick J. Wong <djwong@...nel.org> wrote:
> >
> > On Wed, Jan 15, 2025 at 12:55:47AM +0100, Pali Rohár wrote:
> > > On Wednesday 15 January 2025 09:29:14 ronnie sahlberg wrote:
> > > > On Wed, 15 Jan 2025 at 07:54, Pali Rohár <pali@...nel.org> 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 am not sure if for the cifs client doing this by emulating xattrs.
> > > > I have bad memories of the emulated xattrs.
> > > >
> > > > What about extending ioctl(FS_IOC_GETFLAGS)? There are plenty of spare
> > > > flags there
> > >
> > > Are FS_IOC_GETFLAGS/FS_IOC_SETFLAGS flags preserved across regular
> > > "cp -a" or "rsync -someflag" commands? I'm just worried to not invent
> >
> > No, none of them are.  We should perhaps talk to the util-linux folks
> > about fixing cp.
> >
> 
> I don't think it is a good idea to start copying these attributes with existing
> cp -a without any opt-in with mount option or new cp command line option.
> 
> After all, smb client already exports the virtual xattr "smb3.dosattrib", but
> it is not listed by listxattr, so cp -a does not pick it up anyway.
> 
> You could just as well define a standard virtual xattr "system.fs.fsxattr"
> that implements an alternative interface for FS_IOC_FS[GS]ETXATTR
> but it would have to be opt-in to show up in listxattr().
> 
> > > new way how to get or set flags which would not be understood by
> > > existing backup or regular "copy" applications. Because the worst thing
> > > which can happen is adding new API which nobody would use and basically
> > > will not gain those benefits which should have them... Like if I move or
> > > copy file from one filesystem to another to not loose all those
> > > attributes.
> > >
> > > > and you even have NTFS.readonly ~= Linux.immutable so ... :-)
> > >
> > > I know it :-) I have not explicitly written it in the email, but put
> > > this information into one of the options what can be possible to do.
> > > The bad thing about this option for remote filesystems is that
> > > Linux.immutable can be cleared only by root (or process which privilege
> > > which nobody does not normally have), but on Windows system (and also
> > > when exported over SMB) it can be cleared by anybody who can modify file
> > > (based on ACL). So with this Linux will start blocking to do some
> > > operation with file, which Windows fully allows. And this very user
> > > unfriendly, specially if also wine wants to benefit from it, as wine
> > > normally is not going to be run under root (or special capabilities).
> > >
> > > > To me to feels like the flags you want to implement would fit
> > > > "somewhat naturally" there.
> > >
> > > So thank you and others for this FS_IOC_GETFLAGS opinion. Maybe this
> > > looks like a better solution?
> >
> > FS_IOC_FS[GS]ETXATTR captures a superset of file attributes from
> > FS_IOC_[GS]ETFLAGS, please use the former if available.
> >
> 
> I agree. Flags that you define in the FS_XFLAG_* namespace,
> should also be defined in the STATX_ATTR_* namepsace.
> 
> Looking at the FILE_ATTRIBUTE_* flags defined in SMB protocol
>  (fs/smb/common/smb2pdu.h) I wonder how many of them will be
> needed for applications beyond the obvious ones that were listed.

Well they only asked for seven of them. ;)

I chatted with Ted about this yesterday, and ... some of the attributes
(like read only) imply that you'd want the linux server to enforce no
writing to the file; some like archive seem a little superfluous since
on linux you can compare cmtime from the backup against what's in the
file now; and still others (like hidden/system) might just be some dorky
thing that could be hidden in some xattr because a unix filesystem won't
care.

And then there are other attrs like "integrity stream" where someone
with more experience with windows would have to tell me if fsverity
provides sufficient behaviors or not.

But maybe we should start by plumbing one of those bits in?  I guess the
gross part is that implies an ondisk inode format change or (gross)
xattr lookups in the open path.

(This is the point where I declare that except for applying a mandatory
Thunderbolt firmware update a month ago I haven't touched Windows since
2002, and this is the extent of my interest in the topic.)

--D

> Thanks,
> Amir.

Powered by blists - more mailing lists