ecryptfs file permissions broken with kernel 2.6.36-rc2

[Rocko]

There seems to be an incompatibility between kernel 2.6.36-rc2 and earlier kernel versions when using ecryptfs (I'm using ecryptfs-utils v83-0ubuntu3 on an ext4 file system).

The following output from "ls -il" shows the problem:

ls: cannot access enctest/file1: No such file or directory
ls: cannot access enctest/sub: No such file or directory
total 12
545077 -????????? ? ? ? ? ? file1
545075 -rw-r--r-- 1 root root 3 2010-08-24 08:53 file3-2.6.36
545078 d????????? ? ? ? ? ? sub

file2-2.6.36 was created after mounting the ecryptfs folder with kernel 2.6.36-rc2. The others were created after mounting with kernel 2.6.35.3. Their inodes and filenames look fine but the other information is corrupted.

[Rocko (rockorequin)]

It also seems that the filename created with 2.6.36-rc2 wasn't actually encrypted, although the folder _was_ mounted with ecryptfs and the option ecryptfs_enable_filename_crypto=y when the file was created. The unmounted file system shows as:

drwxr-xr-x 2 root root 4096 2010-08-24 08:46 ECRYPTFS_FNEK_ENCRYPTED.FWbHtjpMW4PshkQYqeqfXg.U0JuQXr1L9kl5EZf1rz1pCTkRUosaIlIjfE--
-rw-r--r-- 1 root root 12288 2010-08-24 08:46 ECRYPTFS_FNEK_ENCRYPTED.FWbHtjpMW4PshkQYqeqfXg.U0JuQXr1L9kl5XIV47v4Cjghfg43P44xFJ---
-rw-r--r-- 1 root root 12288 2010-08-24 08:53 file3-2.6.36

The contents of the file were encrypted, though.

[Kalle Valo (kvalo)]

I saw the same with 2.6.36-rc1-wl+ (from wireless-testing, basically rc1 plus some wireless patches). I reported it here:

http://lkml.org/lkml/2010/8/17/412

For me this was very serious because it corrupted some of my data. I stopped using ecryptfs after this incident.

[Tyler Hicks (tyhicks)]

Hi, thanks for reporting this bug.

When a lookup happens, we lookup the plaintext name in the lower file system. If it isn't found and file name encryption is enabled, we encrypt the file name and look that up in the lower file system.

Commit 21edad32205e97dc7ccb81a85234c77e760364c8 introduced a regression where only the plaintext file name is used, no matter if file name encryption is enabled or not. This patch was released in 2.6.36-rc1.

[Jeremy Foshee (jeremyfoshee)]

Sorry for all the changes Tyler. I changed it to linux intending for it to be under the Ubuntu Distro, but I did it incorrectly. I've fixed that, but as a result it took more steps than I'd planned.

~JFo

[Tyler Hicks (tyhicks)]

On Tue Aug 24, 2010 at 03:51:04PM -0000, Jeremy Foshee <email address hidden> wrote:
> Sorry for all the changes Tyler. I changed it to linux intending for it
> to be under the Ubuntu Distro, ...

No problem, but I don't know if Ubuntu needs to track this one. It is a
regression that is only in 2.6.36-rc1 and -rc2. I plan on having a fix
in by the time -rc3 is released.

Tyler

[Rocko (rockorequin)]

Thanks for the info. I manually changed those two calls to ecryptfs_lookup_one_lower in inode.c back to lookup_one_len and it fixed the problem. Don't you just love patches that are released for bugs that don't exist any more just in case the patch might be useful sometime in the future? :)

But could this commit have resulted in the data loss that Kalle Valo reported? It seems to be just related to the file name/permissions/ownerships/size information and it made writing to (and reading of) files with encrypted filenames impossible.

[Kalle Valo (kvalo)]

Rocko <email address hidden> writes:

> But could this commit have resulted in the data loss that Kalle Valo
> reported? It seems to be just related to the file
> name/permissions/ownerships/size information and it made writing to (and
> reading of) files with encrypted filenames impossible.

Difficult to be sure. But as I saw corruption only in my home directory,
not anywhere else, and immeadiately during the first boot of rc1, it's
very difficult to believe that something else than ecryptfs would have
caused this.

After fsck and booting to an older kernel I saw some of the directories
twice in my home directory, for example Documents and Downloads. I
assume gnome created a new set of directories because it wasn't able to
open the encrypted ones and that caused the corruption. But I'm making
wild guesses here and can be way off.

--
Kalle Valo

[Tyler Hicks (tyhicks)]

I've pushed a fix into the ecryptfs next branch: http://git.kernel.org/?p=linux/kernel/git/ecryptfs/ecryptfs-2.6.git;a=commit;h=b4ef26e06ce0c4877bd5a736b0dfb318a4fb9002

[Tyler Hicks (tyhicks)]

On Wed Aug 25, 2010 at 09:07:16AM -0000, Kalle Valo <email address hidden> wrote:
> Rocko <email address hidden> writes:
>
> After fsck and booting to an older kernel I saw some of the directories
> twice in my home directory, for example Documents and Downloads. I
> assume gnome created a new set of directories because it wasn't able to
> open the encrypted ones and that caused the corruption. But I'm making
> wild guesses here and can be way off.
>

I hope that this was the extent of the 'corruption'. You shouldn't have
been able to reach any of your existing files with encrypted names and
any new files would have unencrypted names. When rebooting into an older
kernel, you could see two files with same name because one had file name
'foo', which was unencrypted in the lower file system and the other was
the encrypted version of file name 'foo' in the lower file system.
getdents() would return 2 files of the name 'foo', but only one could be
looked up.

I imagine that if you remove any newly created files under the
2.6.36-rc{1,2} kernels (they should be easy to locate in the lower file
system because the file names don't start with ECRYPTFS_FNEK_ENCRYPTED
and are plaintext), everything should be back to normal.

I am sorry for the inconvenience.

Tyler

[Tyler Hicks (tyhicks)]

Patch (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=93c3fe40c279f002906ad14584c30671097d4394) released in 2.6.36-rc3 (http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.36-rc3).

[Jeremy Foshee (jeremyfoshee)]

set to Triaged as there is no assigned resource.

[Rocko (rockorequin)]

Actually this has been fixed upstream since 2.6.36-rc3.