ecryptfs breaks lstat/readlink size assumption
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Customization Kit |
Won't Fix
|
Undecided
|
Unassigned | ||
eCryptfs |
Fix Released
|
Medium
|
Tyler Hicks | ||
dpkg (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Lucid |
Won't Fix
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
High
|
Ubuntu Kernel Team | ||
Lucid |
Fix Released
|
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,
Changed in ecryptfs: | |
assignee: | nobody → Tyler Hicks (tyhicks) |
importance: | Undecided → Medium |
status: | New → Triaged |
tags: | added: kernel-series-unknown |
Changed in ecryptfs: | |
status: | Triaged → In Progress |
Changed in dpkg (Ubuntu): | |
status: | New → Won't Fix |
Changed in dpkg (Ubuntu Lucid): | |
status: | New → Won't Fix |
I think the regression was caused by the fix for bug #390833.