linux-kernel - Re: Immutable vs read-only for Windows compatibility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4b0H5hQv0ocD75j@dread.disaster.area>
Date: Wed, 15 Jan 2025 10:32:47 +1100
From: Dave Chinner <david@...morbit.com>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Pali Rohár <pali@...nel.org>,
	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 Tue, Jan 14, 2025 at 04:44:55PM -0500, Chuck Lever wrote:
> On 1/14/25 4:10 PM, Pali Rohár wrote:
> > > 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

"attr" is a poor choice for an attribute class (yes, naming is
hard...). It's a windows file attribute class, the name should
reflect that.

However, my main problem with this approach is that it will be
pretty nasty in terms of performance regressions. xattr lookup is
*much* more expensive than reading a field out of the inode itself.

If you want an example of the cost of how a single xattr per file
can affect the performance of CIFS servers, go run dbench (a CIFS
workload simulator) with and without xattrs. The difference in
performance storing a single xattr per file is pretty stark, and it
only gets worse as we add more xattrs. i.e. xattrs like this will
have significant performance implications for all file create,
lookup/stat and unlink operations.

IOWs, If this information is going to be stored as an xattr, it
needs to be a single xattr with a well defined bit field as it's
value (i.e. one bit per attribute). The VFS inode can then cache
that bitfield with minimal addition overhead during the first
lookup/creation/modification for the purpose of fast, low overhead,
statx() operation.

> 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.

Even the filesystems that store this information natively should
support the xattr interface - they just return the native
information in the xattr format, and then every application has a
common way to change these attributes. (i.e. change the xattr to
modify the attributes, statx to efficiently sample them.

-Dave.
-- 
Dave Chinner
david@...morbit.com