linux-ext4 - Re: [PATCH 3/3] ext4: implemet new ioctls to set and get superblock parameters

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] [day] [month] [year] [list]

Message-ID: <20250912031414.GD3703006@mit.edu>
Date: Thu, 11 Sep 2025 23:14:14 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: linux-ext4@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH 3/3] ext4: implemet new ioctls to set and get superblock
 parameters

On Thu, Sep 11, 2025 at 03:40:19PM -0700, Darrick J. Wong wrote:
>
> What's the difference between _FL_FEATURES and _FL_EDIT_FEATURES?

We have three sets of 

_FL_FEATURES allows the user to set the features via:

	__u32 feature_compat;
	__u32 feature_incompat;
	__u32 feature_ro_compat;

... while _FS_EDIT_FEATURES allows the user to set or clear specific
feature or feature(s) using these fields:

	__u32 set_feature_compat_mask;
	__u32 set_feature_incompat_mask;
	__u32 set_feature_ro_compat_mask;
	__u32 clear_feature_compat_mask;
	__u32 clear_feature_incompat_mask;
	__u32 clear_feature_ro_compat_mask;

I originally only implemented _FS_EDIT_EFATURES but it turns out that
given how tune2fs() and e2p_edit_feateurs2() was implemented,
_FS_FEATURES was a lot more convenient.  But I kept _FS_EDIT_FEATURES
in case some other users wanted an easy way to, say, "just enable
feature X" using a single ioctl.

> > +#define EXT4_TUNE_CLEAR_COMPAT_SUPP (0)
> > +#define EXT4_TUNE_CLEAR_INCOMPAT_SUPP (0)
> > +#define EXT4_TUNE_CLEAR_RO_COMPAT_SUPP \
> > +		(EXT4_FEATURE_RO_COMPAT_LARGE_FILE |	\
> > +		 EXT4_FEATURE_RO_COMPAT_DIR_NLINK |	\
> > +		 EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE |	\
> > +		 EXT4_FEATURE_RO_COMPAT_PROJECT)
> 
> Is it actually safe to clear these without scanning the filesystem to
> make sure nobody's using these features?

Hmm.... probably not.  For some of these features, tune2fs will issue
a "pleas run e2fsck -f" before mounting the file system.  All of these
featrues tune2fs will allow being cleared on a mounted file system,
but looking at this more closely, I probably *shouldn't* have allowed
tune2fs to remove the feature wile the file system is mounted.  (For
example, tune2fs -O ^project" will try to clear they project quota
inode even if the file system is mounted, hilarity would soon
follow...)

						- Ted