linux-kernel - Re: [PATCH] Update atime from future.

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: <424C1F3A-E96F-485B-BAE5-02CE41C0DBFF@whamcloud.com>
Date:	Tue, 4 Dec 2012 17:22:32 -0700
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	yangsheng <sickamd@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	"adilger@...ger.ca" <adilger@...ger.ca>
Subject: Re: [PATCH] Update atime from future.

On 2012-12-04, at 13:24, Dave Chinner <david@...morbit.com> wrote:
> On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote:
>> Relatime should update the inode atime if it is more than a day in the
>> future.  The original problem seen was a tarball that had a bad atime,
>> but could also happen if someone fat-fingers a "touch".  The future
>> atime will never be fixed.  Before the relatime patch, the future atime
>> would be updated back to the current time on the next access.
> 
> So if someone accidentally changes time back a few days, access
> times go backwards for everything?

And they will go forward again if the files are accessed again in the future. 

> That doesn't sound right to me -
> it's going to seriously screw up backups and other scanners that use
> atime to determine "newly accessed files"....

I think it is equally as easy to say that if someone accidentally sets the time too far in the future (e.g. 2102 instead of 2012) for a while, then the atimes will be even more broken since the kernel will never update them again even after the clock is fixed. 

The point is that the behaviour before the relatime patch was that the kernel updated the atime to the current time as the kernel knows about it, it didn't make any decision about "the past" or "the future".

Relatime is about reducing the frequency of atime updates, not about deciding that one timestamp is more correct than another. 

I'd be ok to change the margin for what constitutes a "future" time (a few days or a week?), but if atime updates happen once a day for times in the past  I don't think it is incorrect to update the atime if it is more than a day in the future. 

Cheers, Andreas

> IMO, if you fat-finger a manual atime update or use atimes direct
> from tarballs, then that's your problem as a user and not the
> responsibility of the kernel to magically fix for you....
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/