linux-ext4 - Re: How is e2fsck's time_fudge supposed to behave?

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]

Message-ID: <5509CAF0.7030402@redhat.com>
Date:	Wed, 18 Mar 2015 13:58:56 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Jan Kara <jack@...e.cz>
CC:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: How is e2fsck's time_fudge supposed to behave?

On 3/17/15 12:32 PM, Jan Kara wrote:
> On Fri 13-03-15 17:31:18, Eric Sandeen wrote:

...

>> So unless I'm missing something, the whole fudge_time dance does nothing
>> except change the message, and after reading lots of words in the e2fsck.conf
>> manpage ;) this bit seems relevant as to the intent:
>>
>>> So by default, we allow the superblock  times  to
>>> be  fudged  by  up to 24 hours.
>>
>> I had the impression that "allow" meant "ignore" but this still triggers
>> exactly the same action and correction.  Is that as intended?
>>
>> I'll send a patch do a printf and take no other action if inside the
>> fudge_time window, if that seems like the right thing to do.
>   The actions became the same after commit
> 87aca2ad028b9 (e2fsck: fix last mount time and last write time in preen
> mode). Previously only fudged values were allowed to be fixed in the preen
> mode. The question is whether we now want to change e2fsck to just ignore
> difference within fudge or whether we just stop doing that fudge thing.
> Either makes sense to me...

Oh, thanks, I had missed that.  Funny that OpenSUSE also set broken_system_clock;
Fedora had been doing that too.  For the same reasons.  o_O

The problem I'm still seeing is that if the clock is off by under 24h, we still
do fix_problem(), and set E2F_FLAG_PROBLEMS_FIXED, so check_if_skip() doesn't allow
a skip.  This happens on every single boot.

It sure seems like the intent was to completely ignore superblock time deltas under
24h... I guess I'll send a patch to do that, and see what Ted thinks.

Thanks,
-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