ecryptfs_create leaves empty file in lower directory upon failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Medium
|
Tim Sally |
Bug Description
ecryptfs_
To reproduce:
---
gentoo-virt mnt # mount -it ecryptfs /mnt/.ecryptfs-ext3 /mnt/ecryptfs-ext3/ -o \
ecryptfs_
gentoo-virt ecryptfs-ext3 # echo "camellia cipher test" > /mnt/ecryptfs-
-bash: /mnt/ecryptfs-
---
Relevant log entries:
---
Mar 6 10:15:57 gentoo-virt kernel: write_tag_3_packet: Unable to generate code for cipher [camellia]
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_
Mar 6 10:15:57 gentoo-virt kernel: Error writing headers; rc = [-22]
---
Note that the steps to reproduce are taking advantage of another bug that allows invalid ciphers to be specified at mount time. I should probably open another bug for proper cipher support in eCryptfs at mount.
Changed in ecryptfs: | |
assignee: | nobody → tyhicks |
importance: | Undecided → Medium |
status: | New → Triaged |
Tyler Hicks (tyhicks) wrote : | #1 |
tags: | added: kernel |
Lasse Kärkkäinen (tronic+mb48) wrote : | #2 |
Problems observed when running out of disk space:
- Corrupted file being created, causes these messages when reading:
[20487.078883] Valid eCryptfs headers not found in file header region or xattr region
[20487.078888] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
(sorry, don't have a log of the messages given when actually writing)
- Several minutes of I/O blocking for applications trying to write:
[20521.101463] INFO: task transmission:7651 blocked for more than 120 seconds.
[20521.101467] "echo 0 > /proc/sys/
[20521.101469] transmission D 00000000ffffffff 0 7651 1 0x00000000
[20521.101474] ffff8800c098dc38 0000000000000086 0000000000000000 0000000000015880
[20521.101478] ffff8801add2c7c0 0000000000015880 0000000000015880 0000000000015880
[20521.101482] 0000000000015880 ffff8801add2c7c0 0000000000015880 0000000000015880
[20521.101486] Call Trace:
[20521.101494] [<ffffffff810da
[20521.101498] [<ffffffff81527
[20521.101501] [<ffffffff810da
[20521.101504] [<ffffffff81527
[20521.101507] [<ffffffff810da
[20521.101511] [<ffffffff81078
[20521.101515] [<ffffffff810e4
[20521.101518] [<ffffffff810e6
[20521.101523] [<ffffffff81276
[20521.101526] [<ffffffff810e6
[20521.101529] [<ffffffff81135
[20521.101532] [<ffffffff81134
[20521.101535] [<ffffffff81130
[20521.101537] [<ffffffff81131
[20521.101540] [<ffffffff81132
[20521.101543] [<ffffffff81120
[20521.101545] [<ffffffff81120
[20521.101548] [<ffffffff8111c
[20521.101551] [<ffffffff8111c
[20521.101555] [<ffffffff81012
- The application does not get reported ENOSPC as it should
Tim Sally (tsally) wrote : | #3 |
Taking a look at this today.
Changed in ecryptfs: | |
assignee: | Tyler Hicks (tyhicks) → Tim Sally (tsally) |
status: | Triaged → In Progress |
Tyler Hicks (tyhicks) wrote : | #4 |
Hey Tim - I fixed this bug and the patch is sitting in the eCryptfs next branch, waiting for the 3.6 merge window.
I didn't tag the patch with this bug, but with a newer bug for the same problem. Here's where the patch went out to the mailing list:
http://
Oops, forgot to show that the empty file was still there after the echo failed: ext3/test /mnt/.ecryptfs- ext3/test ext3/test ext3/test
---
gentoo-virt mnt # du -h /mnt/ecryptfs-
0 /mnt/ecryptfs-
0 /mnt/.ecryptfs-
---
Here's the expected output after a successful create in an eCryptfs mount: ext3/test /mnt/.ecryptfs- ext3/test ext3/test ext3/test
---
gentoo-virt mnt # du -h /mnt/ecryptfs-
0 /mnt/ecryptfs-
12K /mnt/.ecryptfs-
---