ecryptfs does not handle symlinks within bzr

Jamie-

A few notes...

 * I'm going to add bzr to the affected packages, in case those guys have an idea of what might be going on, and what this error actually means. Its possible that bzr is doing something "smart" by looking at underlying data, perhaps?

This looks to be a regression in the ecryptfs kernel code, probably introduced by the filename encryption patch.

Testing your methodology on an ecryptfs WITH filename encryption, it seems to work fine. However, WITHOUT filename encryption, symlink creation seems to break.

I'm pretty sure it has something to do with the actual creation of the symlink. If I untar the tarball in /tmp first, and then rsync -aP to my Private directory, the problem does not exist. I don't understand the difference between the way tar creates symlinks and rsync does, but whatever that difference is, seems to trigger the problem.

I'm subscribing Tyler to the bug. Hopefully he can track down the fix.

:-Dustin

Thanks for the bug report Jamie, this one would have been easily to slip by.

It looks like an off-by-one error in the eCryptfs kernel code. We're tacking on an extra byte to the symlink target. Dustin pointed this out to me and I was able to verify it with `strace readlink -n bar`. Here's the interesting line:

readlink("bar", "foo", 64) = 4

It is reading 4 chars, but since we're adding an extra NULL character (string terminator), most applications don't care. I'm guessing that only something like a version control system would have caught it. :)

Working to trace down the problem now.

Awesome, thanks for tracking that down, Tyler.

I have subscribed Tim Gardner to the bug. Hopefully he can apply that to our kernel soon.

Thanks,
:-Dustin

I have looked at our source and I think bzr is just doing the equivalent of

  python -c 'import os;print repr(os.readlink("foo"))'

so you should be able to test if that causes a problem. My guess is
that Python, which can handle strings with embedded nuls, is (perhaps
reasonably) giving back "bar\0".

Cool, thanks for the explanation, Martin.

Actually, bzr has revealed a bug deeply buried in our code ;-) Thanks for that!

:-Dustin

I'm marking the bzr task 'invalid', and assigning the kernel task to Tim.

I'm also going to mark the ecryptfs-utils (userspace) task invalid as well, since it's a bug in the kernel space.

:-Dustin

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=e8782a447782a69b423bb91741d2669018eef899

This bug was fixed in the package linux - 2.6.28-7.18

---------------
linux (2.6.28-7.18) jaunty; urgency=low

  [ Alok Kataria ]

  * SAUCE: (drop after 2.6.29) x86: add a synthetic TSC_RELIABLE feature
    bit
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: add X86_FEATURE_HYPERVISOR feature bit
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: Hypervisor detection and get tsc_freq
    from hypervisor
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: Add a synthetic TSC_RELIABLE feature
    bit.
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: Skip verification by the watchdog for
    TSC clocksource.
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: VMware: Fix vmware_get_tsc code
    - LP: #319945
  * SAUCE: (drop after 2.6.29) x86: vmware: look for DMI string in the
    product serial key
    - LP: #319945

  [ Andy Whitcroft ]

  * SAUCE: toshiba_acpi -- pull in current -dev version of driver
    - LP: #269831
  * SAUCE: toshiba_acpi -- add acpi hotkey kernel thread
    - LP: #269831
  * move toshiba laptops back from tlsup to toshiba_acpi
    - LP: #269831

  [ Aneesh Kumar K.V ]

  * SAUCE: (revert before 2.6.28.y update) ext4: Fix the delalloc
    writepages to allocate blocks at the right offset.
  * SAUCE: (revert before 2.6.28.y update) ext4: avoid ext4_error when
    mounting a fs with a single bg
  * SAUCE: (revert before 2.6.28.y update) ext4: Don't overwrite
    allocation_context ac_status
  * SAUCE: (revert before 2.6.28.y update) ext4: Add blocks added during
    resize to bitmap
  * SAUCE: (revert before 2.6.28.y update) ext4: Use
    EXT4_GROUP_INFO_NEED_INIT_BIT during resize
  * SAUCE: (revert before 2.6.28.y update) ext4: cleanup mballoc header
    files
  * SAUCE: (revert before 2.6.28.y update) ext4: don't use blocks freed but
    not yet committed in buddy cache init
  * SAUCE: (revert before 2.6.28.y update) ext4: Fix race between
    read_block_bitmap() and mark_diskspace_used()
  * SAUCE: (revert before 2.6.28.y update) ext4: Fix the race between
    read_inode_bitmap() and ext4_new_inode()
  * SAUCE: (revert before 2.6.28.y update) ext4: Use new buffer_head flag
    to check uninit group bitmaps initialization
  * SAUCE: (revert before 2.6.28.y update) ext4: mark the blocks/inode
    bitmap beyond end of group as used
  * SAUCE: (revert before 2.6.28.y update) ext4: Don't allow new groups to
    be added during block allocation
  * SAUCE: (revert before 2.6.28.y update) ext4: Init the complete page
    while building buddy cache
  * SAUCE: (revert before 2.6.28.y update) ext4: Fix s_dirty_blocks_counter
    if block allocation failed with nodelalloc

  [ Hannes Eder ]

  * SAUCE: (drop after 2.6.29) x86: vmware - fix sparse warnings
    - LP: #319945

  [ Luke Yelavich ]

  * hid modules have hyphens instead of underscores in their names

  [ Mark Fasheh ]

  * SAUCE: (revert before 2.6.28.y update) jbd2: Add BH_JBDPrivateStart

  [ Theodore Ts'o ]

  * SAUCE: (revert before 2.6.28.y update) ext4: Add support for non-native
    signed/unsigned htree hash algorithms
  * SAUCE: (revert before 2.6.28.y update) ext4: tone down
    ext4_da_writepages warnings
  * SAUCE: (revert before 2.6.28.y...