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
| ||
|
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-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists