linux-ext4 - Re: [PATCH] ext4: Support "check=none" "nocheck" mount options

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]

Date:	Wed, 11 Jan 2012 03:07:33 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Josh Boyer <jwboyer@...hat.com>, "Theodore Ts'o" <tytso@....edu>,
	linux-ext4@...r.kernel.org, kernel-team@...oraproject.org
Subject: Re: [PATCH] ext4: Support "check=none" "nocheck" mount options

On 2012-01-10, at 10:43 AM, Eric Sandeen wrote:
> On 1/10/12 11:41 AM, Josh Boyer wrote:
>> The ext2/ext3 filesystems supported "check=none" and "nocheck" as mount options
>> even though that was already the default behavior and it essentially did
>> nothing.  When using ext4 to mount ext2/ext3 filesystems, that mount option
>> causes the mount to fail.  That isn't as backward compatible as it could be,
>> so add support to ext4 to accept the option.
> 
> The only thing ext2 does with those options today is to clear the flag,
> and I can't find anything in userspace or kernelspace which would have set
> it in any case.  It seem dead, but we do need the compatibility in ext4
> if it's to handle ext2&3 seamlessly, I guess.

At a minimum the use of obsolete options like this should print a warning
at mount time so that there is some chance the user will notice and remove
the old option from their config.  Otherwise it is impossible to even get
rid of old useless cruft like this if we need to maintain functionally-useless
compatibility forever.

Dredging through my memories, I recall that this option used to disable
the checks done at mount(?) time that compared the bits set in the block
and inode bitmaps against the summary values in the group descriptors
(AFAIR).  Or maybe it was comparing the group descriptor summary values
against the superblock values?

In any case, I can't imagine why a user would have this set for a kernel
option that might have last been valid 10 years ago, and why the 5 users
in the world that might have this set cannot simply remove it from their
fstab, since it does absolutely nothing?

>> ---
>> fs/ext4/super.c |    7 ++++++-
>> 1 files changed, 6 insertions(+), 1 deletions(-)
>> 
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 3e1329e..5ff09e7 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1333,7 +1333,7 @@ enum {
>> 	Opt_nomblk_io_submit, Opt_block_validity, Opt_noblock_validity,
>> 	Opt_inode_readahead_blks, Opt_journal_ioprio,
>> 	Opt_dioread_nolock, Opt_dioread_lock,
>> -	Opt_discard, Opt_nodiscard, Opt_init_itable, Opt_noinit_itable,
>> +	Opt_discard, Opt_nodiscard, Opt_init_itable, Opt_noinit_itable, Opt_nocheck,
>> };
>> 
>> static const match_table_t tokens = {
>> @@ -1409,6 +1409,8 @@ static const match_table_t tokens = {
>> 	{Opt_init_itable, "init_itable=%u"},
>> 	{Opt_init_itable, "init_itable"},
>> 	{Opt_noinit_itable, "noinit_itable"},
>> +	{Opt_nocheck, "check=none"},
>> +	{Opt_nocheck, "nocheck"},
>> 	{Opt_err, NULL},
>> };
>> 
>> @@ -1905,6 +1907,9 @@ set_qf_format:
>> 		case Opt_noinit_itable:
>> 			clear_opt(sb, INIT_INODE_TABLE);
>> 			break;
>> +		case Opt_nocheck:
>> +			/* ext2/ext3 used to "support" this option.  Silently eat it */
>> +			break;
>> 		default:
>> 			ext4_msg(sb, KERN_ERR,
>> 			       "Unrecognized mount option \"%s\" "
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html