ecryptfs file permissions broken with kernel 2.6.36-rc2
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Linux |
Fix Released
|
Undecided
|
Unassigned | |
| | eCryptfs |
Critical
|
Tyler Hicks | ||
| | linux (Ubuntu) |
Critical
|
Unassigned | ||
Bug Description
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) wrote : | #1 |
| Kalle Valo (kvalo) wrote : | #2 |
I saw the same with 2.6.36-rc1-wl+ (from wireless-testing, basically rc1 plus some wireless patches). I reported it here:
http://
For me this was very serious because it corrupted some of my data. I stopped using ecryptfs after this incident.
| Tyler Hicks (tyhicks) wrote : | #3 |
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 21edad32205e97d
| Changed in ecryptfs: | |
| assignee: | nobody → Tyler Hicks (tyhicks) |
| importance: | Undecided → Critical |
| status: | New → In Progress |
| Jeremy Foshee (jeremyfoshee) wrote : | #4 |
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
| affects: | ecryptfs → linux |
| Changed in linux (Ubuntu): | |
| assignee: | nobody → Tyler Hicks (tyhicks) |
| importance: | Undecided → Critical |
| status: | New → In Progress |
| Changed in linux: | |
| importance: | Critical → Undecided |
| status: | In Progress → New |
| assignee: | Tyler Hicks (tyhicks) → nobody |
| Tyler Hicks (tyhicks) wrote : Re: [Bug 623087] Re: ecryptfs file permissions broken with kernel 2.6.36-rc2 | #5 |
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
| Changed in ecryptfs: | |
| assignee: | nobody → Tyler Hicks (tyhicks) |
| importance: | Undecided → Critical |
| status: | New → In Progress |
| Rocko (rockorequin) wrote : | #6 |
Thanks for the info. I manually changed those two calls to ecryptfs_
But could this commit have resulted in the data loss that Kalle Valo reported? It seems to be just related to the file name/permission
| Kalle Valo (kvalo) wrote : | #7 |
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/permission
> 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) wrote : | #8 |
I've pushed a fix into the ecryptfs next branch: http://
| Changed in ecryptfs: | |
| status: | In Progress → Fix Committed |
| Changed in linux (Ubuntu): | |
| assignee: | Tyler Hicks (tyhicks) → nobody |
| Tyler Hicks (tyhicks) wrote : | #9 |
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_
and are plaintext), everything should be back to normal.
I am sorry for the inconvenience.
Tyler
| tags: | added: kernel-key |
| Jeremy Foshee (jeremyfoshee) wrote : | #11 |
set to Triaged as there is no assigned resource.
| Changed in linux (Ubuntu): | |
| status: | In Progress → Triaged |
| Rocko (rockorequin) wrote : | #12 |
Actually this has been fixed upstream since 2.6.36-rc3.
| Changed in linux (Ubuntu): | |
| status: | Triaged → Fix Released |
| Changed in linux: | |
| status: | New → Fix Released |


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. FWbHtjpMW4PshkQ YqeqfXg. U0JuQXr1L9kl5EZ f1rz1pCTkRUosaI lIjfE-- FNEK_ENCRYPTED. FWbHtjpMW4PshkQ YqeqfXg. U0JuQXr1L9kl5XI V47v4Cjghfg43P4 4xFJ---
-rw-r--r-- 1 root root 12288 2010-08-24 08:46 ECRYPTFS_
-rw-r--r-- 1 root root 12288 2010-08-24 08:53 file3-2.6.36
The contents of the file were encrypted, though.