<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/ecryptfs, branch v3.2.52</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs/ecryptfs?h=v3.2.52</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs/ecryptfs?h=v3.2.52'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-11-16T16:47:19Z</updated>
<entry>
<title>eCryptfs: check for eCryptfs cipher support at mount</title>
<updated>2012-11-16T16:47:19Z</updated>
<author>
<name>Tim Sally</name>
<email>tsally@atomicpeace.com</email>
</author>
<published>2012-07-12T23:10:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=50a2114dde86ea598918716f1b44fdc88f3692d8'/>
<id>urn:sha1:50a2114dde86ea598918716f1b44fdc88f3692d8</id>
<content type='text'>
commit 5f5b331d5c21228a6519dcb793fc1629646c51a6 upstream.

The issue occurs when eCryptfs is mounted with a cipher supported by
the crypto subsystem but not by eCryptfs. The mount succeeds and an
error does not occur until a write. This change checks for eCryptfs
cipher support at mount time.

Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
https://bugs.launchpad.net/ecryptfs/+bug/338914

Signed-off-by: Tim Sally &lt;tsally@atomicpeace.com&gt;
Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Copy up POSIX ACL and read-only flags from lower mount</title>
<updated>2012-11-16T16:47:18Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-06-11T22:42:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=916fef09cb43ee4aad40129b3f9e3fd4bb1c641f'/>
<id>urn:sha1:916fef09cb43ee4aad40129b3f9e3fd4bb1c641f</id>
<content type='text'>
commit 069ddcda37b2cf5bb4b6031a944c0e9359213262 upstream.

When the eCryptfs mount options do not include '-o acl', but the lower
filesystem's mount options do include 'acl', the MS_POSIXACL flag is not
flipped on in the eCryptfs super block flags. This flag is what the VFS
checks in do_last() when deciding if the current umask should be applied
to a newly created inode's mode or not. When a default POSIX ACL mask is
set on a directory, the current umask is incorrectly applied to new
inodes created in the directory. This patch ignores the MS_POSIXACL flag
passed into ecryptfs_mount() and sets the flag on the eCryptfs super
block depending on the flag's presence on the lower super block.

Additionally, it is incorrect to allow a writeable eCryptfs mount on top
of a read-only lower mount. This missing check did not allow writes to
the read-only lower mount because permissions checks are still performed
on the lower filesystem's objects but it is best to simply not allow a
rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw
mount is valid and still allowed.

https://launchpad.net/bugs/1009207

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Stefan Beller &lt;stefanbeller@googlemail.com&gt;
Cc: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Call lower -&gt;flush() from ecryptfs_flush()</title>
<updated>2012-10-17T02:49:54Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-09-13T01:38:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4dcbf47bac95e0b7cb4e6fa5347318117a19b580'/>
<id>urn:sha1:4dcbf47bac95e0b7cb4e6fa5347318117a19b580</id>
<content type='text'>
commit 64e6651dcc10e9d2cc6230208a8e6c2cfd19ae18 upstream.

Since eCryptfs only calls fput() on the lower file in
ecryptfs_release(), eCryptfs should call the lower filesystem's
-&gt;flush() from ecryptfs_flush().

If the lower filesystem implements -&gt;flush(), then eCryptfs should try
to flush out any dirty pages prior to calling the lower -&gt;flush(). If
the lower filesystem does not implement -&gt;flush(), then eCryptfs has no
need to do anything in ecryptfs_flush() since dirty pages are now
written out to the lower filesystem in ecryptfs_release().

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Write out all dirty pages just before releasing the lower file</title>
<updated>2012-10-17T02:49:53Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-09-13T01:02:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2f45faef3bca26259cb419692f70788e5b77f563'/>
<id>urn:sha1:2f45faef3bca26259cb419692f70788e5b77f563</id>
<content type='text'>
commit 7149f2558d5b5b988726662fe58b1c388337805b upstream.

Fixes a regression caused by:

821f749 eCryptfs: Revert to a writethrough cache model

That patch reverted some code (specifically, 32001d6f) that was
necessary to properly handle open() -&gt; mmap() -&gt; close() -&gt; dirty pages
-&gt; munmap(), because the lower file could be closed before the dirty
pages are written out.

Rather than reapplying 32001d6f, this approach is a better way of
ensuring that the lower file is still open in order to handle writing
out the dirty pages. It is called from ecryptfs_release(), while we have
a lock on the lower file pointer, just before the lower file gets the
final fput() and we overwrite the pointer.

https://launchpad.net/bugs/1047261

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Artemy Tregubenko &lt;me@arty.name&gt;
Tested-by: Artemy Tregubenko &lt;me@arty.name&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Revert to a writethrough cache model</title>
<updated>2012-10-17T02:49:52Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-07-03T23:50:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a50c5c503ad54c9e9995ecadb745c0180a651f69'/>
<id>urn:sha1:a50c5c503ad54c9e9995ecadb745c0180a651f69</id>
<content type='text'>
commit 821f7494a77627fb1ab539591c57b22cdca702d6 upstream.

A change was made about a year ago to get eCryptfs to better utilize its
page cache during writes. The idea was to do the page encryption
operations during page writeback, rather than doing them when initially
writing into the page cache, to reduce the number of page encryption
operations during sequential writes. This meant that the encrypted page
would only be written to the lower filesystem during page writeback,
which was a change from how eCryptfs had previously wrote to the lower
filesystem in ecryptfs_write_end().

The change caused a few eCryptfs-internal bugs that were shook out.
Unfortunately, more grave side effects have been identified that will
force changes outside of eCryptfs. Because the lower filesystem isn't
consulted until page writeback, eCryptfs has no way to pass lower write
errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
that quotas could be bypassed because of the way eCryptfs may sometimes
open the lower filesystem using a privileged kthread.

It would be nice to resolve the latest issues, but it is best if the
eCryptfs commits be reverted to the old behavior in the meantime.

This reverts:
32001d6f "eCryptfs: Flush file in vma close"
5be79de2 "eCryptfs: Flush dirty pages in setattr"
57db4e8d "ecryptfs: modify write path to encrypt page in writepage"

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Tested-by: Colin King &lt;colin.king@canonical.com&gt;
Cc: Colin King &lt;colin.king@canonical.com&gt;
Cc: Thieu Le &lt;thieule@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Initialize empty lower files when opening them</title>
<updated>2012-10-17T02:49:52Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-06-21T06:50:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5fb231c6b869110087e70b42b1dd6b5279045eb3'/>
<id>urn:sha1:5fb231c6b869110087e70b42b1dd6b5279045eb3</id>
<content type='text'>
commit e3ccaa9761200952cc269b1f4b7d7bb77a5e071b upstream.

Historically, eCryptfs has only initialized lower files in the
ecryptfs_create() path. Lower file initialization is the act of writing
the cryptographic metadata from the inode's crypt_stat to the header of
the file. The ecryptfs_open() path already expects that metadata to be
in the header of the file.

A number of users have reported empty lower files in beneath their
eCryptfs mounts. Most of the causes for those empty files being left
around have been addressed, but the presence of empty files causes
problems due to the lack of proper cryptographic metadata.

To transparently solve this problem, this patch initializes empty lower
files in the ecryptfs_open() error path. If the metadata is unreadable
due to the lower inode size being 0, plaintext passthrough support is
not in use, and the metadata is stored in the header of the file (as
opposed to the user.ecryptfs extended attribute), the lower file will be
initialized.

The number of nested conditionals in ecryptfs_open() was getting out of
hand, so a helper function was created. To avoid the same nested
conditional problem, the conditional logic was reversed inside of the
helper function.

https://launchpad.net/bugs/911507

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Cc: John Johansen &lt;john.johansen@canonical.com&gt;
Cc: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Unlink lower inode when ecryptfs_create() fails</title>
<updated>2012-10-17T02:49:51Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-05-22T20:09:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=04661578e516400ca013a5bba87a2868bfb31610'/>
<id>urn:sha1:04661578e516400ca013a5bba87a2868bfb31610</id>
<content type='text'>
commit 8bc2d3cf612994a960c2e8eaea37f6676f67082a upstream.

ecryptfs_create() creates a lower inode, allocates an eCryptfs inode,
initializes the eCryptfs inode and cryptographic metadata attached to
the inode, and then writes the metadata to the header of the file.

If an error was to occur after the lower inode was created, an empty
lower file would be left in the lower filesystem. This is a problem
because ecryptfs_open() refuses to open any lower files which do not
have the appropriate metadata in the file header.

This patch properly unlinks the lower inode when an error occurs in the
later stages of ecryptfs_create(), reducing the chance that an empty
lower file will be left in the lower filesystem.

https://launchpad.net/bugs/872905

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Cc: John Johansen &lt;john.johansen@canonical.com&gt;
Cc: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Copy up attributes of the lower target inode after rename</title>
<updated>2012-09-19T14:05:24Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-09-13T19:00:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=62ae7bbdbb77a210eb839f34dc0d1923a4842dbd'/>
<id>urn:sha1:62ae7bbdbb77a210eb839f34dc0d1923a4842dbd</id>
<content type='text'>
commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream.

After calling into the lower filesystem to do a rename, the lower target
inode's attributes were not copied up to the eCryptfs target inode. This
resulted in the eCryptfs target inode staying around, rather than being
evicted, because i_nlink was not updated for the eCryptfs inode. This
also meant that eCryptfs didn't do the final iput() on the lower target
inode so it stayed around, as well. This would result in a failure to
free up space occupied by the target file in the rename() operation.
Both target inodes would eventually be evicted when the eCryptfs
filesystem was unmounted.

This patch calls fsstack_copy_attr_all() after the lower filesystem
does its -&gt;rename() so that important inode attributes, such as i_nlink,
are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
and eCryptfs can drop its final reference on the lower inode.

http://launchpad.net/bugs/561129

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Tested-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Properly check for O_RDONLY flag before doing privileged open</title>
<updated>2012-07-25T03:11:44Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-06-12T18:17:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=03d200117c06fde714344f8f4f0301f609959b53'/>
<id>urn:sha1:03d200117c06fde714344f8f4f0301f609959b53</id>
<content type='text'>
commit 9fe79d7600497ed8a95c3981cbe5b73ab98222f0 upstream.

If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.

The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>eCryptfs: Fix lockdep warning in miscdev operations</title>
<updated>2012-07-25T03:11:44Z</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2012-06-11T17:21:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8b1e1ea3fa0b1de9a5eead6bab0c563617b9a2b'/>
<id>urn:sha1:b8b1e1ea3fa0b1de9a5eead6bab0c563617b9a2b</id>
<content type='text'>
commit 60d65f1f07a7d81d3eb3b91fc13fca80f2fdbb12 upstream.

Don't grab the daemon mutex while holding the message context mutex.
Addresses this lockdep warning:

 ecryptfsd/2141 is trying to acquire lock:
  (&amp;ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [&lt;ffffffffa029c213&gt;] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]

 but task is already holding lock:
  (&amp;(*daemon)-&gt;mux){+.+...}, at: [&lt;ffffffffa029c2ec&gt;] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;(*daemon)-&gt;mux){+.+...}:
        [&lt;ffffffff810a3b8d&gt;] lock_acquire+0x9d/0x220
        [&lt;ffffffff8151c6da&gt;] __mutex_lock_common+0x5a/0x4b0
        [&lt;ffffffff8151cc64&gt;] mutex_lock_nested+0x44/0x50
        [&lt;ffffffffa029c5d7&gt;] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
        [&lt;ffffffffa029b744&gt;] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
        [&lt;ffffffffa029a24e&gt;] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
        [&lt;ffffffffa02960f8&gt;] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
        [&lt;ffffffffa0290f80&gt;] ecryptfs_create+0x130/0x250 [ecryptfs]
        [&lt;ffffffff811963a4&gt;] vfs_create+0xb4/0x120
        [&lt;ffffffff81197865&gt;] do_last+0x8c5/0xa10
        [&lt;ffffffff811998f9&gt;] path_openat+0xd9/0x460
        [&lt;ffffffff81199da2&gt;] do_filp_open+0x42/0xa0
        [&lt;ffffffff81187998&gt;] do_sys_open+0xf8/0x1d0
        [&lt;ffffffff81187a91&gt;] sys_open+0x21/0x30
        [&lt;ffffffff81527d69&gt;] system_call_fastpath+0x16/0x1b

 -&gt; #0 (&amp;ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
        [&lt;ffffffff810a3418&gt;] __lock_acquire+0x1bf8/0x1c50
        [&lt;ffffffff810a3b8d&gt;] lock_acquire+0x9d/0x220
        [&lt;ffffffff8151c6da&gt;] __mutex_lock_common+0x5a/0x4b0
        [&lt;ffffffff8151cc64&gt;] mutex_lock_nested+0x44/0x50
        [&lt;ffffffffa029c213&gt;] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
        [&lt;ffffffff811887d3&gt;] vfs_read+0xb3/0x180
        [&lt;ffffffff811888ed&gt;] sys_read+0x4d/0x90
        [&lt;ffffffff81527d69&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
</feed>
