linux-ext4 - Re: buggy_init_scritps and e2fsprogs 1.41.9

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] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2009 12:38:49 +0200
From:	Stephan Kulow <coolo@...e.de>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: buggy_init_scritps and e2fsprogs 1.41.9

On Friday 11 September 2009 02:55:03 Theodore Tso wrote:
> On Thu, Sep 10, 2009 at 10:57:54PM +0200, Stephan Kulow wrote:
> > The work flow is as such:
> > - boot into live cd, live cd thinks system is UTC, mounts sda1 (ro)
> >   at 9am, umounts cleanly, updates mount time to 11am (hardware clock)
> 
> That doesn't make any sense.  The mount time is only set if the
> filesystem is mounted read/write.  So if you only mounted the
> filesystem read/only, the mount time wouldn't be changed.  Watch:
> 
I wasn't certain if it also happens with ro, so I put the ro in ().

> 
> Now, if the Live CD is going to be repairing a filesystem, it should
> mount the root filesystem read/only, extract the time zone, fix the
> system clock, and only then mount the filesystem read/write.
> 
> Or the Live CD should fix the system clock over the network before it
> tries mounting any hard drives.  The point is, there are ways for the
> Live CD to do the right thing.  If it's not willing to do that, then
> its init scripts are buggy.  :-)
> 
It doesn't matter if the live init scripts are buggy or not, because the
real system's fsck will be the one to complain about future mounts.

Ok, perhaps it's clearer if you think about it this way:
- installing openSUSE using local time
- boot ubuntu live cd (assuming utc), mount /data (in the future), 
  umount cleanly
- reboot into openSUSE (without buggy init scripts) 
   -> UNEXPECTED INCONSISTENCY, need to repair

I think this is pretty much expected as ubuntu has little chance to figure out 
the timezone of the system using /data normally.

What you're saying is basically: screw everyone living east and using dual 
boot. fsck repairs way more serious problems without any problem, but if I 
share data between ubuntu and openSUSE I need to go into single mode 
afterwards?

At least consider this one:

--- a/e2fsck/super.c
+++ b/e2fsck/super.c
@@ -836,7 +836,7 @@ void check_super_block(e2fsck_t ctx)
                pctx.num = fs->super->s_wtime;
                problem = PR_0_FUTURE_SB_LAST_WRITE;
                if (fs->super->s_wtime <= (__u32) ctx->now + ctx->time_fudge)
-                       problem = PR_0_FUTURE_SB_LAST_MOUNT_FUDGED;
+                       problem = PR_0_FUTURE_SB_LAST_WRITE_FUDGED;
                if (fix_problem(ctx, problem, &pctx)) {
                        fs->super->s_wtime = ctx->now;
                        ext2fs_mark_super_dirty(fs);

Greetings, Stephan
--
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