linux-ext4 - Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards]

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: <4AEB1E9E.9020408@redhat.com>
Date:	Fri, 30 Oct 2009 12:13:02 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Alexey Fisher <bug-track@...her-privat.net>
CC:	Greg Freemyer <greg.freemyer@...il.com>,
	Ted Augustine <taugustine@...hpathways.com>,
	linux-ext4@...r.kernel.org
Subject: Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption
 with 	2.6.32-rc1 and upwards]

Alexey Fisher wrote:
> Am Freitag, den 30.10.2009, 11:14 -0500 schrieb Eric Sandeen:
>> Alexey Fisher wrote:
>>> Am Freitag, den 30.10.2009, 10:14 -0500 schrieb Eric Sandeen:
>> ...
>>
>>>> After a little brief digging I'm not sure when the xfs mount option went 
>>>> in or why...
>>>>
>>>> But for both
>>>>
>>>> xfs: mount -o ro,norecovery
>>>>
>>>> and
>>>>
>>>> ext[34]: mount -o ro,noload
>>>>
>>>> I don't think either one should touch the disk.
>>>>
>>>> Also, both should skip journal replay if you set the block device 
>>>> readonly prior to mount (hdparm -r can do this).
>>> Interesting tip, thank you.
>>> But there is some problems:
>>> 1. "hdparm -r" will set complete drive to ro mode. This is bad if i
>>> use /dev/sda1 for root and /dev/sda5 need to be forced readonly.
>> So point it at the partition not the drive:
>>
>> [root@...n ~]# hdparm -r 1 /dev/sda1
>>
>> /dev/sda1:
>>   setting readonly to 1 (on)
>>   readonly      =  1 (on)
>> [root@...n ~]# hdparm -r /dev/sda2
>>
>> /dev/sda2:
>>   readonly      =  0 (off)
>>
>> It doesn't change the hardware, it sets a flag on the kernel's block 
>> device structure.
> 
> ok, got it. Every day learning something new.
> It was not clear for me, after i read man hdparm: "Get/set read-only
> flag for the device.  When set,  Linux  disallows write operations on
> the device."
> 
>>> 2. the fact xfs and ext[3,4] use different options for true_ro make
>>> things complicated.
>> the hazards of being an open source sysadmin I guess.
> 
> :( are there any plans to unify mount options?

Some of this gets done; barrier options now match across xfs & ext4, I'm 
actually just writing a patch for ext3.

Doing the same for noload/norecovery would be pretty trivial.

>>> 3. the definition of ro is broken.
>> depends on what you mean by ro.  A user can only read from the 
>> filesystem so it is accurate in that respect.  Is "ro" for the fs or the 
>> bdev?  Semantic differences but not necessarily broken.
> 
> Hmm... bdev. any chance to do temporary recovery and load it as external
> journal if ro used? Anyway, you already pointed me to hdparm, so i can
> use it too.

There were patches floated to in-ram recovery for those blocks so that 
you could have a consistent fs w/o touching the disk but it didn't seem 
to get far.

>>> 4. many frustrated admins who mounted part of raid1 only with "-o ro"
>> Dunno what you mean by that ...
> 
> raid1 is down, so you need for some reasons to mount ro only one disk of
> the array. Needed to do it for short time (i used -o ro), now i know
> this probably was a bad idea (bad me, should read documentation). Need
> to check my raid now.  Suddenly i'm not alone who doing this :(


oh I see.  Yup....

-Eric
--
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