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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250117175755.lctf5ezhhtdznt6m@pali>
Date: Fri, 17 Jan 2025 18:57:55 +0100
From: Pali Rohár <pali@...nel.org>
To: Steve French <smfrench@...il.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
	Amir Goldstein <amir73il@...il.com>,
	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 Friday 17 January 2025 11:51:54 Steve French wrote:
> On Fri, Jan 17, 2025 at 11:39 AM Darrick J. Wong <djwong@...nel.org> wrote:
> >
> > 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:
> <...>
> > > 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.
> >
> 
> We have talked about some of these missing flags in the past, but the
> obvious ones that would be helpful i (e.g. is used in other operating
> systems when view directories in the equivalent of the "Files" GUI is
> checking FILE_ATTRIBUTE_OFFLINE to determine whether to query icons,
> and additional metadata for files).  In the past Unix used to have
> various ways to determine this, but it is fairly common for files to
> be tiered (where the data is in very slow storage offline - so should
> only be opened and read by apps that really need to - not things like
> GUIs browsing lists of files) so that attribute could be helpful.
> 
> The other two obvious ones (missing in Linux but that some other OS
> have filesystems which support) discussed before were
> FILE_ATTRIBUTE_INTEGRITY_STREAM which could be set for files that need
> stronger data integrity guarantees (if a filesystem allows files to be
> marked for stronger data integrity guarantees) , and
> FILE_ATTRIBUTE_NO_SCRUB_DATA that indicates integrity checks can be
> skipped for this particular file.
> -- 
> Thanks,
> 
> Steve

Thank you for information about integrity stream and these new things
around. I have not included them into my initial list because I have not
used them yet. That it why I listed only seven. But as I wrote in the
other email, whatever API is chosen, it should be prepared for extending
and integrity stream sounds like something could be included there.