Patchwork UBUNTU: [Config] ext3 defaults to ordered mode

login
register
mail settings
Submitter Surbhi Palande
Date Jan. 21, 2010, 10:34 a.m.
Message ID <1264070060-4310-1-git-send-email-surbhi.palande@canonical.com>
Download mbox | patch
Permalink /patch/43424/
State Accepted
Delegated to: Stefan Bader
Headers show

Comments

Surbhi Palande - Jan. 21, 2010, 10:34 a.m.
This patch fixes bug 510067 on launchpad.
This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
threat of older data being inadvertently exposed, that arises from mounting the
ext3 fs with the data=writeback mode.

Do consider merging this for Karmic.


From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
From: Surbhi Palande <surbhi.palande@canonical.com>
Date: Wed, 20 Jan 2010 15:28:31 +0200
Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode

BugLink: http://bugs.launchpad.net/bugs/510067
Ignore: yes

To prevent a security threat of older data being inadvertently exposed,
the default mount option of ext3 should be ordered instead of writeback. This
patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
to ensure the data=ordered mode for an ext3 fs mount.

Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
---
 debian.master/config/config.common.ports  |    2 +-
 debian.master/config/config.common.ubuntu |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Tim Gardner - Jan. 21, 2010, 1:20 p.m.
Surbhi Palande wrote:
> This patch fixes bug 510067 on launchpad.
> This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
> to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
> threat of older data being inadvertently exposed, that arises from mounting the
> ext3 fs with the data=writeback mode.
> 
> Do consider merging this for Karmic.
> 
> 
> From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
> From: Surbhi Palande <surbhi.palande@canonical.com>
> Date: Wed, 20 Jan 2010 15:28:31 +0200
> Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode
> 
> BugLink: http://bugs.launchpad.net/bugs/510067
> Ignore: yes
> 
> To prevent a security threat of older data being inadvertently exposed,
> the default mount option of ext3 should be ordered instead of writeback. This
> patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
> to ensure the data=ordered mode for an ext3 fs mount.
> 
> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
> ---
>  debian.master/config/config.common.ports  |    2 +-
>  debian.master/config/config.common.ubuntu |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
> index 39ee289..4e22aeb 100644
> --- a/debian.master/config/config.common.ports
> +++ b/debian.master/config/config.common.ports
> @@ -817,7 +817,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>  CONFIG_EXT2_FS_SECURITY=y
>  CONFIG_EXT2_FS_XATTR=y
>  # CONFIG_EXT2_FS_XIP is not set
> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>  CONFIG_EXT3_FS=y
>  CONFIG_EXT3_FS_POSIX_ACL=y
>  CONFIG_EXT3_FS_SECURITY=y
> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
> index 462c1c1..2477234 100644
> --- a/debian.master/config/config.common.ubuntu
> +++ b/debian.master/config/config.common.ubuntu
> @@ -943,7 +943,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>  CONFIG_EXT2_FS_SECURITY=y
>  CONFIG_EXT2_FS_XATTR=y
>  # CONFIG_EXT2_FS_XIP is not set
> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>  CONFIG_EXT3_FS=y
>  CONFIG_EXT3_FS_POSIX_ACL=y
>  CONFIG_EXT3_FS_SECURITY=y

Since we're already thinking about performance degradation with ext4, is
this going to have an adverse impact on ext3 performance? It seems to me
that the vulnerability window that this closes is vanishingly small, and
really only applies to multi-user machines (I think). After all, who
cares if the vulnerability exists on your laptop? You're likely the only
user anyway.

rtg
Stefan Bader - Jan. 21, 2010, 1:35 p.m.
Tim Gardner wrote:
> Surbhi Palande wrote:
>> This patch fixes bug 510067 on launchpad.
>> This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>> to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
>> threat of older data being inadvertently exposed, that arises from mounting the
>> ext3 fs with the data=writeback mode.
>>
>> Do consider merging this for Karmic.
>>
>>
>> From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
>> From: Surbhi Palande <surbhi.palande@canonical.com>
>> Date: Wed, 20 Jan 2010 15:28:31 +0200
>> Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode
>>
>> BugLink: http://bugs.launchpad.net/bugs/510067
>> Ignore: yes
>>
>> To prevent a security threat of older data being inadvertently exposed,
>> the default mount option of ext3 should be ordered instead of writeback. This
>> patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>> to ensure the data=ordered mode for an ext3 fs mount.
>>
>> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
>> ---
>>  debian.master/config/config.common.ports  |    2 +-
>>  debian.master/config/config.common.ubuntu |    2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
>> index 39ee289..4e22aeb 100644
>> --- a/debian.master/config/config.common.ports
>> +++ b/debian.master/config/config.common.ports
>> @@ -817,7 +817,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>  CONFIG_EXT2_FS_SECURITY=y
>>  CONFIG_EXT2_FS_XATTR=y
>>  # CONFIG_EXT2_FS_XIP is not set
>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>  CONFIG_EXT3_FS=y
>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>  CONFIG_EXT3_FS_SECURITY=y
>> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
>> index 462c1c1..2477234 100644
>> --- a/debian.master/config/config.common.ubuntu
>> +++ b/debian.master/config/config.common.ubuntu
>> @@ -943,7 +943,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>  CONFIG_EXT2_FS_SECURITY=y
>>  CONFIG_EXT2_FS_XATTR=y
>>  # CONFIG_EXT2_FS_XIP is not set
>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>  CONFIG_EXT3_FS=y
>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>  CONFIG_EXT3_FS_SECURITY=y
> 
> Since we're already thinking about performance degradation with ext4, is
> this going to have an adverse impact on ext3 performance? It seems to me
> that the vulnerability window that this closes is vanishingly small, and
> really only applies to multi-user machines (I think). After all, who
> cares if the vulnerability exists on your laptop? You're likely the only
> user anyway.
> 
> rtg

It will have an impact. But it not only has the security side but also the data
consistency side to it. There seems to be an overall bigger tendency to think of
the ordered option as being the preferable. The initial trigger to look at this
was a report of a fs corruption after a crash. Plus it was our default before
the config option was introduced. And we just failed to notice they silently
change the default there.

-Stefan
Stefan Bader - Jan. 21, 2010, 1:38 p.m.
This restores our original default, prevents some cases of corruption after
crashes and Kees wants it, too.

Surbhi Palande wrote:
> This patch fixes bug 510067 on launchpad.
> This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
> to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
> threat of older data being inadvertently exposed, that arises from mounting the
> ext3 fs with the data=writeback mode.
> 
> Do consider merging this for Karmic.
> 
> 
> From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
> From: Surbhi Palande <surbhi.palande@canonical.com>
> Date: Wed, 20 Jan 2010 15:28:31 +0200
> Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode
> 
> BugLink: http://bugs.launchpad.net/bugs/510067
> Ignore: yes
> 
> To prevent a security threat of older data being inadvertently exposed,
> the default mount option of ext3 should be ordered instead of writeback. This
> patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
> to ensure the data=ordered mode for an ext3 fs mount.
> 
> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>

> ---
>  debian.master/config/config.common.ports  |    2 +-
>  debian.master/config/config.common.ubuntu |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
> index 39ee289..4e22aeb 100644
> --- a/debian.master/config/config.common.ports
> +++ b/debian.master/config/config.common.ports
> @@ -817,7 +817,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>  CONFIG_EXT2_FS_SECURITY=y
>  CONFIG_EXT2_FS_XATTR=y
>  # CONFIG_EXT2_FS_XIP is not set
> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>  CONFIG_EXT3_FS=y
>  CONFIG_EXT3_FS_POSIX_ACL=y
>  CONFIG_EXT3_FS_SECURITY=y
> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
> index 462c1c1..2477234 100644
> --- a/debian.master/config/config.common.ubuntu
> +++ b/debian.master/config/config.common.ubuntu
> @@ -943,7 +943,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>  CONFIG_EXT2_FS_SECURITY=y
>  CONFIG_EXT2_FS_XATTR=y
>  # CONFIG_EXT2_FS_XIP is not set
> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>  CONFIG_EXT3_FS=y
>  CONFIG_EXT3_FS_POSIX_ACL=y
>  CONFIG_EXT3_FS_SECURITY=y
Tim Gardner - Jan. 21, 2010, 2 p.m.
I am not in agreement. ORDERED was the implicit default _before_ Karmic
because there was no other option. However, Karmic has _not_ had ORDERED
set since the first 2.6.30 based release. Changing ORDERED at this point
 changes the fundamental behavior of the file system. I think we need to
solicit the considered opinion of our platform brethren. I have no idea
how this might affect select() or poll() or other file system
notification mechanisms.

SRU policy states that patches must fix a real problem. IMHO this does
not fix the root issue, which is the crash, _not_ the file system
corruption. No file system code will be able to withstand crashes at the
right critical point.

Steve, Martin - any thoughts on this? Am I just blowing things all out
of proportion?

rtg

P.S. I have no problem with setting ORDERED on Lucid.

Stefan Bader wrote:
> This restores our original default, prevents some cases of corruption after
> crashes and Kees wants it, too.
> 
> Surbhi Palande wrote:
>> This patch fixes bug 510067 on launchpad.
>> This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>> to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
>> threat of older data being inadvertently exposed, that arises from mounting the
>> ext3 fs with the data=writeback mode.
>>
>> Do consider merging this for Karmic.
>>
>>
>> From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
>> From: Surbhi Palande <surbhi.palande@canonical.com>
>> Date: Wed, 20 Jan 2010 15:28:31 +0200
>> Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode
>>
>> BugLink: http://bugs.launchpad.net/bugs/510067
>> Ignore: yes
>>
>> To prevent a security threat of older data being inadvertently exposed,
>> the default mount option of ext3 should be ordered instead of writeback. This
>> patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>> to ensure the data=ordered mode for an ext3 fs mount.
>>
>> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
> Acked-by: Stefan Bader <stefan.bader@canonical.com>
> 
>> ---
>>  debian.master/config/config.common.ports  |    2 +-
>>  debian.master/config/config.common.ubuntu |    2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
>> index 39ee289..4e22aeb 100644
>> --- a/debian.master/config/config.common.ports
>> +++ b/debian.master/config/config.common.ports
>> @@ -817,7 +817,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>  CONFIG_EXT2_FS_SECURITY=y
>>  CONFIG_EXT2_FS_XATTR=y
>>  # CONFIG_EXT2_FS_XIP is not set
>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>  CONFIG_EXT3_FS=y
>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>  CONFIG_EXT3_FS_SECURITY=y
>> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
>> index 462c1c1..2477234 100644
>> --- a/debian.master/config/config.common.ubuntu
>> +++ b/debian.master/config/config.common.ubuntu
>> @@ -943,7 +943,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>  CONFIG_EXT2_FS_SECURITY=y
>>  CONFIG_EXT2_FS_XATTR=y
>>  # CONFIG_EXT2_FS_XIP is not set
>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>  CONFIG_EXT3_FS=y
>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>  CONFIG_EXT3_FS_SECURITY=y
> 
>
Surbhi Palande - Jan. 21, 2010, 4:40 p.m.
IMHO, there are many features on todays distributions focusing on
security in multi user environment. Besides, a filesystem should
gurantee atleast the rwx permsisions set by any user. The writeback mode
seems to expose data which a user may not want to share. IMHO, for a
distribution the security feature afforded by ordered mode is necessary.
Users who crave for super performance and do not care for data loss,
should explicitly mount their filesystems with writeback mode and
barriers = 0. But by default, we should support both barriers=1 and
data=ordered.

I am also forwarding an email exchange on ext4 mailing list regarding this:


-------- Original Message --------
Subject: Re: [2.6.30 and later] file corruption on ext3 filesystem.
Date: Mon, 11 Jan 2010 15:13:24 -0500
From: Ric Wheeler <rwheeler@redhat.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
CC: david@fromorbit.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
References: <201001080254.o082sOXB018423@www262.sakura.ne.jp>
<20100108123641.GB8654@discord.disaster>
<201001082215.EJH52647.JLtFSFFVQOHMOO@I-love.SAKURA.ne.jp>
<20100108151915.GC8654@discord.disaster>
<201001091153.FAC21374.OFOFMJQVOSFLtH@I-love.SAKURA.ne.jp>

On 01/08/2010 09:53 PM, Tetsuo Handa wrote:
> Dave Chinner wrote:
>
>> I agree that it is very wrong, but it's a known problem with writeback
>> mode in ext3:
>>
>> http://thread.gmane.org/gmane.linux.kernel/818044/focus=819977
>>
>> More info as to how this change came about and the proposed but not
>> yet realised fixes:
>>
>> http://lwn.net/Articles/328363/
>>
> Thank you for the pointer.
>
> Indeed, most Linux boxes are used by single user.
> But implicitly importing other deleted file's data is still annoying
> even if the box is used by only one user.
>
> When I was trying to identify the steps to reproduce, I got ./a.out
replaced
> by the deleted .bash_history due to power failure. I executed ./a.out
as root
> without knowing that the file contains deleted .bash_history , and many
> commands listed in deleted .bash_history are executed as root.
> I thought my box was cracked and trojaned. :-(
>

Fedora and some other distributions changed the default back to data
ordered mode in order to avoid exactly this kind of mess. Even if you
are on a single user system, this behavior is certainly unexpected for
most users :-)

Ric

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




Tim Gardner wrote:
> I am not in agreement. ORDERED was the implicit default _before_ Karmic
> because there was no other option. However, Karmic has _not_ had ORDERED
> set since the first 2.6.30 based release. Changing ORDERED at this point
>  changes the fundamental behavior of the file system. I think we need to
> solicit the considered opinion of our platform brethren. I have no idea
> how this might affect select() or poll() or other file system
> notification mechanisms.
> 
> SRU policy states that patches must fix a real problem. IMHO this does
> not fix the root issue, which is the crash, _not_ the file system
> corruption. No file system code will be able to withstand crashes at the
> right critical point.
> 
> Steve, Martin - any thoughts on this? Am I just blowing things all out
> of proportion?
> 
> rtg
> 
> P.S. I have no problem with setting ORDERED on Lucid.
> 
> Stefan Bader wrote:
>> This restores our original default, prevents some cases of corruption after
>> crashes and Kees wants it, too.
>>
>> Surbhi Palande wrote:
>>> This patch fixes bug 510067 on launchpad.
>>> This patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>>> to ensure the data=ordered mode for an ext3 fs mount. This prevents a security 
>>> threat of older data being inadvertently exposed, that arises from mounting the
>>> ext3 fs with the data=writeback mode.
>>>
>>> Do consider merging this for Karmic.
>>>
>>>
>>> From 6978a248df3aab38476659e164020b35f7b227ad Mon Sep 17 00:00:00 2001
>>> From: Surbhi Palande <surbhi.palande@canonical.com>
>>> Date: Wed, 20 Jan 2010 15:28:31 +0200
>>> Subject: [PATCH] UBUNTU: [Config] ext3 defaults to ordered mode
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/510067
>>> Ignore: yes
>>>
>>> To prevent a security threat of older data being inadvertently exposed,
>>> the default mount option of ext3 should be ordered instead of writeback. This
>>> patch enables the compile time option CONFIG_EXT3_DEFAULTS_TO_ORDERED
>>> to ensure the data=ordered mode for an ext3 fs mount.
>>>
>>> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
>> Acked-by: Stefan Bader <stefan.bader@canonical.com>
>>
>>> ---
>>>  debian.master/config/config.common.ports  |    2 +-
>>>  debian.master/config/config.common.ubuntu |    2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
>>> index 39ee289..4e22aeb 100644
>>> --- a/debian.master/config/config.common.ports
>>> +++ b/debian.master/config/config.common.ports
>>> @@ -817,7 +817,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>>  CONFIG_EXT2_FS_SECURITY=y
>>>  CONFIG_EXT2_FS_XATTR=y
>>>  # CONFIG_EXT2_FS_XIP is not set
>>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>>  CONFIG_EXT3_FS=y
>>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>>  CONFIG_EXT3_FS_SECURITY=y
>>> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
>>> index 462c1c1..2477234 100644
>>> --- a/debian.master/config/config.common.ubuntu
>>> +++ b/debian.master/config/config.common.ubuntu
>>> @@ -943,7 +943,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y
>>>  CONFIG_EXT2_FS_SECURITY=y
>>>  CONFIG_EXT2_FS_XATTR=y
>>>  # CONFIG_EXT2_FS_XIP is not set
>>> -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>>> +CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
>>>  CONFIG_EXT3_FS=y
>>>  CONFIG_EXT3_FS_POSIX_ACL=y
>>>  CONFIG_EXT3_FS_SECURITY=y
>>
> 
>
Ben Hutchings - Jan. 22, 2010, 2:13 a.m.
On Thu, 2010-01-21 at 07:00 -0700, Tim Gardner wrote:
> I am not in agreement. ORDERED was the implicit default _before_ Karmic
> because there was no other option. However, Karmic has _not_ had ORDERED
> set since the first 2.6.30 based release. Changing ORDERED at this point
>  changes the fundamental behavior of the file system. I think we need to
> solicit the considered opinion of our platform brethren. I have no idea
> how this might affect select() or poll() or other file system
> notification mechanisms.

It has no effect.  Filesystems do not support non-blocking I/O (at least
not in the sense that sockets and pipes do).

> SRU policy states that patches must fix a real problem. IMHO this does
> not fix the root issue, which is the crash, _not_ the file system
> corruption.

In general a bug which causes a crash might also corrupt the writeback
cache some time before bringing the system down.  However there are many
classes of bugs that will crash the system without causing such memory
corruption beforehand.  Furthermore, unclean shutdown may be the result
of power loss rather than a crash.  In that case, surely the filesystem
behaviour *is* the root issue, from a kernel maintainer's perspective?

> No file system code will be able to withstand crashes at the
> right critical point.
[...]

So long as a filesystem uses appropriate I/O barriers, and the
underlying system implements them, it is possible to reduce the
possibility of this sort of data corruption nearly to zero.  And that is
what ext3 did by default until recently.

Ben.
Martin Pitt - Jan. 27, 2010, 7:53 a.m.
Hello all,

Tim Gardner [2010-01-21  7:00 -0700]:
> SRU policy states that patches must fix a real problem. IMHO this does
> not fix the root issue, which is the crash, _not_ the file system
> corruption. No file system code will be able to withstand crashes at the
> right critical point.

I have read the bug report now, and TBH I fail to see the security
problem here. If due to a crash I can still read old data from a file,
that just means that my recent attempt to remove/overwrite the data
from a file failed. Well, if the computer had crashed ten microseconds
earlier, and thus the disk wouldn't have managed to write the metadata
either, I would have the very same problem. Or did I misunderstood the
problem here?

I'd be very cautious to change something as fundamental as the file
system behaviour in an SRU. A crash fix is a valid SRU reason, but
this looks like a very intrusive change, not a focused bug fix to me.

Thanks,

Martin
Martin Pitt - Jan. 27, 2010, 7:56 a.m.
Surbhi Palande [2010-01-21 18:40 +0200]:
> >> http://thread.gmane.org/gmane.linux.kernel/818044/focus=819977

Ah, this indeed explains it much better, thanks for the link.

So this rather looks like it should be queued up for -security then?
(Can still be tested in -proposed, of course, but it's not a genuine
SRU).

Martin
Ben Hutchings - Jan. 27, 2010, 1:56 p.m.
On Wed, 2010-01-27 at 08:53 +0100, Martin Pitt wrote:
> Hello all,
> 
> Tim Gardner [2010-01-21  7:00 -0700]:
> > SRU policy states that patches must fix a real problem. IMHO this does
> > not fix the root issue, which is the crash, _not_ the file system
> > corruption. No file system code will be able to withstand crashes at the
> > right critical point.
> 
> I have read the bug report now, and TBH I fail to see the security
> problem here. If due to a crash I can still read old data from a file,
> that just means that my recent attempt to remove/overwrite the data
> from a file failed. Well, if the computer had crashed ten microseconds
> earlier, and thus the disk wouldn't have managed to write the metadata
> either, I would have the very same problem. Or did I misunderstood the
> problem here?
[...]

With the data=writeback setting, it is possible for block allocation to
be committed to disk before the block contents.  This means that a file
which was extended just before a crash may contain data from a
previously deleted file after journal replay, and that can be a security
problem.  See <http://lwn.net/Articles/328363/>.

(The proposed data=guarded setting would fix this problem without the
full overhead of data=ordered, but it has not been accepted yet.)

Ben.
Stefan Bader - Feb. 9, 2010, 3:41 p.m.
After talks with the SRU team, we agreed that this can be regarded as a sort of
regression-release. And by that is applicable as a SRU to bring it back to the
default we had before and will have after.

Applied and pushed.

Patch

diff --git a/debian.master/config/config.common.ports b/debian.master/config/config.common.ports
index 39ee289..4e22aeb 100644
--- a/debian.master/config/config.common.ports
+++ b/debian.master/config/config.common.ports
@@ -817,7 +817,7 @@  CONFIG_EXT2_FS_POSIX_ACL=y
 CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT2_FS_XATTR=y
 # CONFIG_EXT2_FS_XIP is not set
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT3_FS_POSIX_ACL=y
 CONFIG_EXT3_FS_SECURITY=y
diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
index 462c1c1..2477234 100644
--- a/debian.master/config/config.common.ubuntu
+++ b/debian.master/config/config.common.ubuntu
@@ -943,7 +943,7 @@  CONFIG_EXT2_FS_POSIX_ACL=y
 CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT2_FS_XATTR=y
 # CONFIG_EXT2_FS_XIP is not set
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT3_FS_POSIX_ACL=y
 CONFIG_EXT3_FS_SECURITY=y