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: <20250203221955.bgvlkp273o3wnzmf@pali>
Date: Mon, 3 Feb 2025 23:19:55 +0100
From: Pali Rohár <pali@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
	ronnie sahlberg <ronniesahlberg@...il.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Immutable vs read-only for Windows compatibility

On Monday 03 February 2025 22:59:46 Amir Goldstein wrote:
> On Sun, Feb 2, 2025 at 4:23 PM Pali Rohár <pali@...nel.org> wrote:
> > And there is still unresolved issue with FILE_ATTRIBUTE_READONLY.
> > Its meaning is similar to existing Linux FS_IMMUTABLE_FL, just
> > FILE_ATTRIBUTE_READONLY does not require root / CAP_LINUX_IMMUTABLE.
> >
> > I think that for proper support, to enforce FILE_ATTRIBUTE_READONLY
> > functionality, it is needed to introduce new flag e.g.
> > FS_IMMUTABLE_FL_USER to allow setting / clearing it also for normal
> > users without CAP_LINUX_IMMUTABLE. Otherwise it would be unsuitable for
> > any SMB client, SMB server or any application which would like to use
> > it, for example wine.
> >
> > Just to note that FreeBSD has two immutable flags SF_IMMUTABLE and
> > UF_IMMUTABLE, one settable only by superuser and second for owner.
> >
> > Any opinion?
> 
> For filesystems that already support FILE_ATTRIBUTE_READONLY,
> can't you just set S_IMMUTABLE on the inode and vfs will do the correct
> enforcement?
> 
> The vfs does not control if and how S_IMMUTABLE is set by filesystems,
> so if you want to remove this vfs flag without CAP_LINUX_IMMUTABLE
> in smb client, there is nothing stopping you (I think).

Function fileattr_set_prepare() checks for CAP_LINUX_IMMUTABLE when
trying to change FS_IMMUTABLE_FL bit. This function is called from
ioctl(FS_IOC_SETFLAGS) and also from ioctl(FS_IOC_FSSETXATTR).
And when function fileattr_set_prepare() fails then .fileattr_set
callback is not called at all. So I think that it is not possible to
remove the IMMUTABLE flag from userspace without capability for smb
client.

And it would not solve this problem for local filesystems (ntfs or ext4)
when Samba server or wine would want to set this bit.

> How about tackling this one small step at a time, not in that order
> necessarily:
> 
> 1. Implement the standard API with FS_IOC_FS[GS]ETXATTR ioctl
>     and with statx to get/set some non-controversial dosattrib flags on
>     ntfs/smb/vfat
> 2. Wire some interesting dosattrib flags (e.g. compr/enrypt) to local
>     filesystems that already support storing those bits
> 3. Wire network servers (e.g. Samba) to use the generic API if supported
> 4. Add on-disk support for storing the dosattrib flags to more local fs
> 5. Update S_IMMUTABLE inode flag if either FS_XFLAG_IMMUTABLE
>     or FS_DOSATTRIB_READONLY are set on the file
> 
> Thoughts?
> 
> Thanks,
> Amir.