please sync jaunty ecryptfs kernel module with linus' git tree

I made a quick list of the commit difference between the current jaunty and 2.6.29-rc7 git trees. Unfortunately, several of these patches touch quite a bit more than eCryptfs code.

Missing from jaunty kernel:
---
745ca2475a6ac596e3d8d37c2759c0fbe2586227
4c728ef583b3d82266584da5cb068294c09df31e
acfa4380efe77e290d3a96b11cd4c9f24f4fbb18
4eea03539d9a8e3f5056aed690efde1f75535e7b
18b6e0414e42d95183f07d8177e3ff0241abd825
295c896cb95de18004ef5e1b53f44c2ad001f936
---

Added to jaunty kernel (not upstream):
---
c9b68678c51d435e824214926d41e1ab5e9f7b99
---

After taking a closer look through these commits, nothing is jumping out at me as a fix for the syslog messages Dustin included above. Dustin, are you still seeing these messages?

On Thu, Mar 5, 2009 at 3:27 PM, Tyler Hicks <email address hidden> wrote:
> I made a quick list of the commit difference between the current jaunty
> and 2.6.29-rc7 git trees.  Unfortunately, several of these patches touch
> quite a bit more than eCryptfs code.
>
> Missing from jaunty kernel:
> ---
> 745ca2475a6ac596e3d8d37c2759c0fbe2586227
> 4c728ef583b3d82266584da5cb068294c09df31e
> acfa4380efe77e290d3a96b11cd4c9f24f4fbb18
> 4eea03539d9a8e3f5056aed690efde1f75535e7b
> 18b6e0414e42d95183f07d8177e3ff0241abd825
> 295c896cb95de18004ef5e1b53f44c2ad001f936
> ---
>
> Added to jaunty kernel (not upstream):
> ---
> c9b68678c51d435e824214926d41e1ab5e9f7b99
> ---

Thanks a lot, Tyler.

> After taking a closer look through these commits, nothing is jumping out
> at me as a fix for the syslog messages Dustin included above.  Dustin,
> are you still seeing these messages?

Yes, absolutely.

My dmesg output has hundreds of these two sets of error messages:

a)
[ 52.956360] ecryptfs_parse_tag_70_packet: max_packet_size is [56];
real packet size is [51]
[ 52.956368] ecryptfs_decode_and_decrypt_filename: Could not parse
tag 70 packet from filename; copying through filename as-is

b)
[ 62.572708] Valid eCryptfs headers not found in file header region
or xattr region
[ 62.572717] 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

I would really like to focus on getting those two issues resolved.
I'll file two separate bugs.

:-Dustin

I compared the commits to Jaunty ecryptfs versus 2.6.29-rc7 and found these differences (e.g. ecryptfs commits missing in Jaunty):

fs/Kconfig: move ecryptfs out
add a vfs_fsync helper
inode->i_op is never NULL
CRED: Pass credentials through dentry_open()
CRED: Wrap task credential accesses in the eCryptFS filesystem

The one that caught my eye is 'add a vfs_fsync helper'. Quoting from the commit log, "ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the lower file". This is commit 4c728ef583b3d82266584da5cb068294c09df31e.

Tyler - would you care to comment on the possibility that the vfs helper function is the root of the errors that Dustin is seeing? The rest of the missing commits are mostly house keeping stuff and should not have any runtime impact.

Hi Tim - I agree that the vfs_fsync patch is the only one of much interest, but it isn't the cause of Dustin's problems. We have been working together to determine the problem and figured out that he had some non-eCryptfs files in his lower mount point. This is due to a problem where creates can fail and eCryptfs leaves a zero length file around instead of cleaning up after the failed create. The empty file doesn't have the proper eCryptfs header and the kernel module will complain and return -EIO. I've opened a bug up for this:

https://bugs.launchpad.net/ecryptfs/+bug/338826

Tim-

I'm actually suffering from the EXT4 zero-byte-file bug, Bug #317781.

I've added a few comments to that effect.

:-Dustin

Tyler/Tim-

What's our current status here? I don't think Tim has sync'd the ecryptfs kernel code for Jaunty.

Tyler-

What's your recommendation for ecryptfs git commits that should be sync'd from 2.6.29 to Ubuntu's 2.6.28?

:-Dustin

Dustin - other then a couple of system wide commits (vfs creds and some current user macros), I see no substantive difference between Jaunty fs/ecryptfs and the version in Linus tree as of 2.6.29-rc8 a1e4ee22863d41a6fbb24310d7951836cb6dafe7.

Good, thanks, Tim.

:-Dustin

Dustin - I am in agreement with Tim. Sorry I didn't respond quicker.

This bug is closedb but with latest Jaunty packages dmesg still shows:

[ 2028.376354] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2028.376357] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.238093] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.238096] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.320903] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.320907] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.321418] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.321420] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.321490] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.321492] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.598219] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.598222] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.646035] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.646038] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2083.646748] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2083.646751] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2121.974605] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2121.974608] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is
[ 2121.977303] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 2121.977306] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is

Thanks İsmail - I've tried quite a bit and have been unsuccessful in reproducing these messages on my system. If Dustin or İsmail can provide me with an encrypted filename that triggers these messages, I will fix the problem.

Currently, the best way to do this would be to single out which plaintext filename is causing this, set some strange/unique permissions on that file, then find a file in the lower mount point with those permissions. Hopefully we'll have a userspace tool to decrypt the filenames soon.

I still get these error messages. All updates are applied on my system.

[ 6643.280765] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real packet size is [51]
[ 6643.280772] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is

Is there any way to find out what file is causing this and is it harmfull to my data?

bert-

What is the underlying filesystem? ext3? ext4?

:-Dustin

Ext4

grtz
Bert

As the current bug is fixed, I have opened a new bug to address this issue specifically.

Please post further comments to Bug #357345.

:-Dustin