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: <7A0721E1-689F-4B9B-BD8C-86A03DDF20CE@dilger.ca>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ