eCryptfs should initialize existing empty files at open()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
Medium
|
Tyler Hicks | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Colin Ian King | ||
Lucid |
Fix Released
|
Undecided
|
Colin Ian King | ||
Natty |
Fix Released
|
Undecided
|
Colin Ian King | ||
Oneiric |
Fix Released
|
Undecided
|
Colin Ian King | ||
Precise |
Fix Released
|
Undecided
|
Colin Ian King | ||
Quantal |
Fix Released
|
Undecided
|
Colin Ian King |
Bug Description
Empty files left in the lower filesystem cause eCryptfs to return error codes and log error messages when eCryptfs tries to read the metadata. This has been the mode of operation since the beginning of eCryptfs. There is no eCryptfs metadata available, so it seemed appropriate to refuse to open the file.
However, more and more users are having trouble with this poor design. It would not be too difficult to convert the empty file into a proper eCryptfs file in the open() path, just as is done in the create() path.
Currently, users see these messages logged to their syslog:
Valid eCryptfs headers not found in file header region or xattr region
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
Transparently converting the empty file to an eCryptfs file and successfully completing the open() request will greatly improve usability.
WORKAROUND: see comment #19 https:/
Related branches
Changed in ecryptfs: | |
importance: | High → Medium |
tags: | added: precise |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
description: | updated |
Changed in ecryptfs: | |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu): | |
assignee: | nobody → Colin King (colin-king) |
status: | Confirmed → In Progress |
Changed in linux (Ubuntu Precise): | |
assignee: | nobody → Colin King (colin-king) |
status: | New → In Progress |
Changed in linux (Ubuntu Quantal): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Oneiric): | |
assignee: | nobody → Colin King (colin-king) |
status: | New → In Progress |
Changed in linux (Ubuntu Oneiric): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Precise): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Quantal): | |
status: | Fix Committed → Fix Released |
status: | Fix Released → Fix Committed |
tags: | added: verification-needed-oneiric |
Changed in linux (Ubuntu Lucid): | |
assignee: | nobody → Colin King (colin-king) |
status: | New → Fix Committed |
Changed in linux (Ubuntu Natty): | |
assignee: | nobody → Colin King (colin-king) |
status: | New → Fix Committed |
I don't agree with the reasoning here. If the user has disabled passthrough mode, then any file in the lower filesystem that is not regognized by eCryptfs is an error.
eCryptfs should have an fsck which could remove such empty files from lower filesystem or convert those files to encrypted empty files. However, I don't think that filesystem should automatically do such a tricks. (Compare to existing filesystems such as ext4 - it does not automatically try to run fsck and fix logical problems in the filesystem.)
I'd prefer a single error message to syslog about the problem and then automatically remounting ecryptfs read-only. Then I would have to run fsck to fix the issue. Hopefully the syslog entry would point me towards that target.