linux-kernel - Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()

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]

Date:	Thu, 10 Jan 2008 11:46:42 -0500
From:	Peter Staubach <staubach@...hat.com>
To:	Rik van Riel <riel@...hat.com>
CC:	Anton Salikhmetov <salikhmetov@...il.com>,
	Jakob Oestergaard <jakob@...hought.net>,
	Valdis.Kletnieks@...edu, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in
 msync()

Rik van Riel wrote:
> On Thu, 10 Jan 2008 18:56:07 +0300
> "Anton Salikhmetov" <salikhmetov@...il.com> wrote:
>
>   
>> However, I don't see how they will work if there has been
>> something like a sync(2) done after the mmap'd region is
>> modified and the msync call.  When the inode is written out
>> as part of the sync process, I_DIRTY_PAGES will be cleared,
>> thus causing a miss in this code.
>>
>> The I_DIRTY_PAGES check here is good, but I think that there
>> needs to be some code elsewhere too, to catch the case where
>> I_DIRTY_PAGES is being cleared, but the time fields still need
>> to be updated.
>>     
>
> Agreed. The mtime and ctime should probably also be updated
> when I_DIRTY_PAGES is cleared.
>
> The alternative would be to remember that the inode had been
> dirty in the past, and have the mtime and ctime updated on
> msync or close - which would be more complex.

And also remembering that the file times should not be updated
if the pages were modified via a write(2) operation.  Or if
there has been an intervening write(2) operation...

The number of cases to consider and the boundary conditions
quickly make this reasonably complex to get right.  That's why
this is the 4'th or 5'th attempt in the last 18 months or so
to get this situation addressed.

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