Natty SRU: eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate

[Tim Gardner]

On 10/10/2011 02:42 PM, Leann Ogasawara wrote:
> On Sun, 2011-10-09 at 05:12 -0600, Tim Gardner wrote:
>>  From 27ed7cb2b00512e81016419715c1d9b6794b06ae Mon Sep 17 00:00:00 2001
>> From: Tyler Hicks<tyhicks at canonical.com>
>> Date: Fri, 7 Oct 2011 15:54:26 -0500
>> Subject: [PATCH] eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate
>>
>> BugLink: http://bugs.launchpad.net/bugs/745836
>>
>> The ECRYPTFS_NEW_FILE crypt_stat flag is set upon creation of a new
>> eCryptfs file. When the flag is set, eCryptfs reads directly from the
>> lower filesystem when bringing a page up to date. This means that no
>> offset translation (for the eCryptfs file metadata in the lower file)
>> and no decryption is performed. The flag is cleared just before the
>> first write is completed (at the beginning of ecryptfs_write_begin()).
>>
>> It was discovered that if a new file was created and then extended with
>> truncate, the ECRYPTFS_NEW_FILE flag was not cleared. If pages
>> corresponding to this file are ever reclaimed, any subsequent reads
>> would result in userspace seeing eCryptfs file metadata and encrypted
>> file contents instead of the expected decrypted file contents.
>>
>> Data corruption is possible if the file is written to before the
>> eCryptfs directory is unmounted. The data written will be copied into
>> pages which have been read directly from the lower file rather than
>> zeroed pages, as would be expected after extending the file with
>> truncate.
>>
>> This flag, and the functionality that used it, was removed in upstream
>> kernels in 2.6.39 with the following commits:
>>
>> bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e
>> fed8859b3ab94274c986cbdf7d27130e0545f02c
>
> Is there a reason we're not just cherry-picking the upstream patches?
> And so I would assume this patch should be marked as SAUCE?
>
> Thanks,
> Leann
>

Yeah, 'UBUNTU: SAUCE:' for sure. Tyler said in the LP report that 
backporting those 2 commits was getting too involved and complicated. 
Given the simplicity of his ultimate solution I thought the backport 
seemed better.

rtg
-- 
Tim Gardner tim.gardner at canonical.com