| Message ID | 1264070060-4310-1-git-send-email-surbhi.palande@canonical.com |
|---|---|
| State | Accepted |
| Delegated to: | Stefan Bader |
| Headers | show |
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
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
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
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 > >
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 >> > >
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.
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
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
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.
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.
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