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: <CAOQ4uxhh1LDz5zXzqFENPhJ9k851AL3E7Xc2d7pSVVYX4Fu9Jw@mail.gmail.com>
Date: Fri, 17 Jan 2025 19:46:30 +0100
From: Amir Goldstein <amir73il@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
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

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

I may be wrong, but I think there is a confusion in this thread.
I don't think that Pali was looking for filesystems to implement
storing those attributes. I read his email as a request to standardize
a user API to get/set those attributes for the filesystems that
already support them and possibly for vfs to enforce some of them
(e.g. READONLY) in generic code.

Nevertheless, I understand the confusion because I know there
is also demand for storing those attributes by file servers in a
standard way and for vfs to respect those attributes on the host.

Full disclosure - I have an out of tree xfs patch that implements
ioctls XFS_IOC_[GS]ETDOSATTRAT and stashes these
attributes in the unused di_dmevmask space.

Compared to the smb server alternative of storing those attributes
as xattrs on the server, this saves a *lot* of IO in an SMB file browsing
workload, where most of the inodes have large (ACL) xattrs that do
not fit into the inode, because SMB protocol needs to return
those attributes in a response to READDIR(PLUSPLUS), so
it needs to read all the external xattr blocks.

So yeh, I would love to have proper support in xfs...

Thanks,
Amir.