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: <20250104-bonzen-brecheisen-8f7088db32b0@brauner>
Date: Sat, 4 Jan 2025 09:52:44 +0100
From: Christian Brauner <brauner@...nel.org>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: Jan Kara <jack@...e.cz>, Pali Rohár <pali@...nel.org>, 
	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 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?