linux-kernel - Re: [4.1-rc] File was modified, but mtime stayed the same (according to unison)

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: <20150609160455.GS19168@thunk.org>
Date:	Tue, 9 Jun 2015 12:04:55 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Pavel Machek <pavel@....cz>
Cc:	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	kernel list <linux-kernel@...r.kernel.org>, jack@...e.cz
Subject: Re: [4.1-rc] File was modified, but mtime stayed the same (according
 to unison)

On Tue, Jun 09, 2015 at 05:34:29PM +0200, Pavel Machek wrote:
> 
> Ok, I guess mmap() can explain this. So... basically mtime is useless
> in detecting if file have been updated?
> 
> Thats... not welcome.

Using mtime to detect if a file has been updated if there is a process
updating the file at the same time you are trying to take snapshots
and using mtime is inherently racy.

This was much more obvious for file systems with a one second mtime
granularity, but because of mmap(2), it's still not true even if you
have a file system with nanosecond timestamps.

> I see that constantly updating on-disk timestamp is not
> feasible. Could we do something like
> 
>   on page_being_mmapped_rw:
> 	     file.mtime = "future".
> 
>   on last_rw_mmap_disappearing:
>   	     file.mtime = now().
> 
>   stat():
> 	if file.mtime != "future":
> 		result.mtime = file.mtime
> 	else:
> 		result.mtime = now()
> 
> ? I see making stat slower is not welcome, but having to read complete
> files to determine if they were modified is even worse than that...

Doing this would violate POSIX, and would probably break other
programs that would be surprised when mtime goes backwards.  I suspect
a better thing to do is to add a new system call interface which
allows a userspace process to query whether a file is either (a)
opened for read, (b) opened for write, and/or (c) mmap'ed.  Not all
file systems would be able to return this bitfield --- for example, it
wouldn't be possible to do this for NFS, for example, and it's not
clear how this should or could work for overlayfs.

Unison could then be modified to use this new system call interface,
so it can take special care if the file is currently opened for write
or mmap'ed.  Note that because of the mtime granularity issues, which
can be constrained by the on-disk file system field, as well as the
granularity of the hardware clocks available to the system, unison
could get fooled nonetheless.

Regards,

						- Ted
--
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/