ecryptfs breaks lstat/readlink size assumption
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Ubuntu Customization Kit |
Undecided
|
Unassigned | ||
| | eCryptfs |
Medium
|
Tyler Hicks | ||
| | dpkg (Ubuntu) |
Undecided
|
Unassigned | ||
| | Lucid |
Undecided
|
Unassigned | ||
| | linux (Ubuntu) |
High
|
Ubuntu Kernel Team | ||
| | Lucid |
High
|
Ubuntu Kernel Team | ||
Bug Description
Hi
When running dpkg on an ecryptfs partition, I'm hitting assertion failures in dpkg; in this example I'm creating an i386 chroot in my home under lucid amd64:
sudo debootstrap --variant=buildd --arch i386 lucid lucid
[...]
I: Extracting tzdata...
I: Extracting udev...
I: Extracting upstart...
I: Extracting util-linux...
I: Extracting zlib1g...
I: Installing core packages...
W: Failure trying to run: chroot /home/lool/
Running the above command manually:
sudo chroot /home/lool/
dpkg: regarding .../base-
base-files pre-depends on awk
awk is not installed.
dpkg: warning: ignoring pre-dependency problem!
(Reading database ... 50%
dpkg: warning: files list file for package `base-files' missing, assuming package has no files currently installed.
(Reading database ... 0 files and directories currently installed.)
Preparing to replace base-files 5.0.0ubuntu10 (using .../base-
Unpacking replacement base-files ...
dpkg: ../../src/
zsh: abort (core dumped) sudo chroot /home/lool/
I checked the dpkg source code, and in src/archives.
statr= lstat(fnamevb.
[...]
r = readlink(
[...]
assert(r == stab.st_size);
The lstat() manpage states that:
The st_size field gives the size of the file (if it is a regular file
or a symbolic link) in bytes. The size of a symlink is the length of
the pathname it contains, without a trailing null byte.
and the readlink manpage:
RETURN VALUE
On success, readlink() returns the number of bytes placed in buf. On
error, -1 is returned and errno is set to indicate the error.
I believe that ecryptfs is returning the sizes of the backing filesystem objects instead of the sizes of the unencrypted data; this can only break applications IMO since read()/write() is going to return less bytes than the reported (stat()) length.
Thanks,
| Loïc Minier (lool) wrote : | #1 |
| Changed in linux (Ubuntu): | |
| importance: | Undecided → High |
| assignee: | nobody → Ubuntu Kernel Team (ubuntu-kernel-team) |
| Changed in linux (Ubuntu Lucid): | |
| assignee: | nobody → Ubuntu Kernel Team (ubuntu-kernel-team) |
| Dustin Kirkland (kirkland) wrote : | #2 |
Argh, what a mess...
Well, bug #390833 has a work around, albeit inconvenient. ie, users must use du --apparent-size ...
I'm CC'ing Tyler here, since he's the author of the upstream patch and will want to know about this.
| Changed in linux (Ubuntu Lucid): | |
| status: | New → Confirmed |
| Tyler Hicks (tyhicks) wrote : | #3 |
I don't believe this is a regression caused by the fix in bug #390833. The only change that fix made was to the st_blocks field of the stat struct.
The problem that Loïc is seeing is that return value of readlink() and st_size don't match. As far as I can tell, that has always been the case since the inception of the encrypted filename feature in eCryptfs. The reason is that when we create a symbolic link, we have to store the encrypted version of the target path in the sym link file. However, when readlink() is called we decrypt that path and return the unencrypted path, resulting in a difference in readlink()'s return value and the reported st_size of the sym link file.
Loïc, have you been able to successfully use dpkg inside your eCryptfs partition (with encrypted filenames enabled) before? My guess is that either no one has tried this before or the 'assert(r == stab.st_size);' is relatively new.
| Loïc Minier (lool) wrote : | #4 |
Yes, I was running it fine a couple days of earlier, but we did get a dpkg update on 14 Feb.
The assert was committed on Sep 2009 in dpkg:
- do {
- varbufextend(
- r= readlink(
- if (r<0) ohshite(_("unable to read link `%.255s'
- } while ((size_t)r == symlinkfn.size);
+ varbuf_
+ r = readlink(
+ if (r < 0)
+ ohshite(_("unable to read link `%.255s'"), ti->Name);
+ assert(r == stab.st_size);
commit 353b02acb33224b
Author: Guillem Jover <email address hidden>
Date: Wed Sep 30 03:10:27 2009 +0200
dpkg: Use stat size to varbuf_grow the buffer for readlink
Do not expand the buffer indefinitely by trying several times until
the buffer is big enough. Pre-allocate just once using varbuf_grow
with the known size from stat.
that said, I find it hard to blame the dpkg developers for assuming that behavior given that it's the documented one.
Wouldn't it make more sense to consistently return unencrypted sizes/metadata for all syscalls on ecryptfs files?
| Tyler Hicks (tyhicks) wrote : Re: [Bug 524919] Re: ecryptfs breaks lstat/readlink size assumption | #5 |
On 02/26/2010 02:58 AM, Loïc Minier wrote:
> Wouldn't it make more sense to consistently return unencrypted
> sizes/metadata for all syscalls on ecryptfs files?
I agree with you. I think it is reasonable to check if the file is a
symlink and then attempt to decrypt the target. If that's successful,
return the length of the decrypted target.
| Changed in ecryptfs: | |
| assignee: | nobody → Tyler Hicks (tyhicks) |
| importance: | Undecided → Medium |
| status: | New → Triaged |
| Josef Spillner (josefspillner) wrote : | #6 |
Is anybody working on a patch already? I've just been hit by this issue as well. My poor workaround is to run the debootstrap in /tmp.
| tags: | added: kernel-series-unknown |
I'm affected by this in Ubuntu Karmic. I run scratchbox <http://
| Changed in ecryptfs: | |
| status: | Triaged → In Progress |
| Tyler Hicks (tyhicks) wrote : | #8 |
I pushed a fix for this into 2.6.34-rc5 and cc'ed stable:
http://
| Changed in ecryptfs: | |
| status: | In Progress → Fix Released |
| Dustin Kirkland (kirkland) wrote : | #9 |
So this should be fixed in Ubuntu Maverick (or if we cherrypick this fix from -stable) for Lucid.
| Tim Gardner (timg-tpi) wrote : | #10 |
http://
| Pascal de Bruijn (pmjdebruijn) wrote : | #11 |
This is still a problem in Lucid-rc
Users of UbuntuCustomiza
| Pascal de Bruijn (pmjdebruijn) wrote : | #13 |
Indeed, that's how I noticed this problem. UCK does not work on eCryptfs homedirs...
| GerhardGaußling (ggrubbish-web) wrote : | #14 |
Is this also a Problem on ntfs mounts?
I ask this because I get in huge trouble on a hardy->lucid do-release-upgrade -m desktop -d, I think now due to a move of the /usr/share/doc to a ntfs partition because I had not enough space in /usr for the upgrade.
I symlinked the doc-folder on the ntfs partitition to /usr/share/doc then.
Here is the bug report:
https:/
this seems not to be a UCK bug to me
| Changed in uck: | |
| status: | New → Won't Fix |
| Changed in dpkg (Ubuntu): | |
| status: | New → Won't Fix |
| Changed in dpkg (Ubuntu Lucid): | |
| status: | New → Won't Fix |
| Tim Gardner (timg-tpi) wrote : | #16 |
Fix released in Lucid since Ubuntu-2.6.32-23.37
| Changed in linux (Ubuntu): | |
| status: | Confirmed → Fix Released |
| Changed in linux (Ubuntu Lucid): | |
| status: | Confirmed → Fix Released |


I think the regression was caused by the fix for bug #390833.