ecryptfs-utils not working properly with linux kernel 4.8.0-41-generic

[Redsandro]

UPDATE:

I think the problem only exists for unencrypted filenames that would previously pass (by default or) by passing the ecryptfs_passthrough option.

Unencrypted filenames work as expected on kernels <=4.4, but are inaccessable and listed as ???????? in kernels >=4.8.

Original report below:

--------

I have two systems that have a Dropbox folder synced. One of the subfolders contains sensitive data encrypted using ecryptfs. Both were running linux kernel 4.4.0-53-generic.

I have since upgraded one system to use linux kernel 4.8.0-41-generic. Now, the decrypted directory can no longer see groups and owners or read files. All permissions are replaced by questionmarks.

4.8.0-41-generic

$ ll
ls: cannot access 'Contracts': No such file or directory
ls: cannot access 'Documents': No such file or directory
ls: cannot access 'Work': No such file or directory
total 12K
drwxr-x--- 5 redsandro redsandro 4.0K Mar 31 15:54 ./
drwxr-xr-x 7 redsandro redsandro 4.0K Apr 13 13:24 ../
d????????? ? ? ? ? ? Contracts/
d????????? ? ? ? ? ? Documents/
d????????? ? ? ? ? ? Work/

The other machine still works fine.

4.4.0-53-generic:

$ ll
total 56K
drwxr-x--- 5 redsandro redsandro 12K Apr 4 16:11 ./
drwxr-xr-x 8 redsandro redsandro 4.0K Oct 18 13:25 ../
drwxr-xr-x 3 redsandro redsandro 4.0K Nov 2 18:50 Contracts/
drwxr-xr-x 11 redsandro redsandro 4.0K Mar 9 17:03 Documents/
drwxr-xr-x 3 redsandro redsandro 4.0K Mar 4 2013 Work/

For both machines:
$ apt version ecryptfs-utils
111-0ubuntu1.1

[Redsandro (redsandro)]

Additional info.

Upgraded machine:

$ uname -a
Linux myLaptop 4.8.0-41-generic #44~16.04.1-Ubuntu SMP Fri Mar 3 17:11:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Working machine:
$ uname -a
Linux myDesktop 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1682410

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.11 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc7

[Redsandro (redsandro)]

Hi @jsalisbury, absolutely. Please wait until I have access to said laptop. I will get back to this.

@brad-figg I'm sorry, I've analized the logfile and decided there's too much seemingly irrelevant private information. Be more specific and I will supply more details.

[Redsandro (redsandro)]

@jsalisbury is there a packaged way that takes into account drivers and virtualbox dkms builds?

I'm trying out linux-generic-hwe-16.04-edge (version 4.10.0.14.11) now.

[Redsandro (redsandro)]

(Update: 4.10.0.14.11 does not fix the problem)

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Redsandro (redsandro)]

Latest I tried was linux 4.10.0-26.30 through the hwe-edge package.
ecryptfs still didn't mount properly.

I switched back to 4.4.0. Ecryptfs works fine again.

[Redsandro (redsandro)]

@jsalisbury I tried kernel 4.12.0 and the problem exists.

Can we re-open this? Something clearly changed between 4.4 and 4.8. And it's not fixed in 4.10 or 4.12.

Does someone know what is going on? Using the same mount options, only kernel 4.4.0 and lower will mount the ecryptfs share. Newer kernels will display the ???????? as mentioned in the original report.

/tmp/test1 on /tmp/test2 type ecryptfs (rw,relatime,ecryptfs_fnek_sig=a1111b22c3d4e5ee,ecryptfs_sig=a1111b22c3d4e5ee,ecryptfs_cipher=aes,ecryptfs_key_bytes=32)

[Redsandro (redsandro)]

INTERESTING: In the new kernels, you can still write new files and read them. You cannot read files written in 'old' kernels.

But when booting the old kernel, you can read ALL files, including the one written using the newer kernel!

Booting back in 4.8, 4.10 or 4.12, and again you can only read the new file, not the old files. Are there some kind of stricter options that are backwards compatible since 4.8?

[Redsandro (redsandro)]

I think the problem only exists for unencrypted filenames that would previously pass (by default or) by passing the ecryptfs_passthrough option.

Unencrypted filenames work as expected on kernels <=4.4, but are inaccessable and listed as ???????? in kernels >=4.8.

I've tried the mount option ecryptfs_passthrough=yes, ecryptfs_passthrough=y and ecryptfs_passthrough in the commandline:

sudo /bin/mount -it ecryptfs /tmp/.files /tmp/files -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_enable_filename_crypto=yes,ecryptfs_passthrough,ecryptfs_sig=a1b2c3...,ecryptfs_fnek_sig=a1b2c3...)

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1682410

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Redsandro (redsandro)]

I have tried 3 different laptops with 3 different distro's.
Ubuntu 16.04.1, Ubuntu 16.04.3 and Linux Mint 17.
Also I've tried about 8 different kernels.

For that reason, a bug report with apport-collect, containing all my hardware serials and stored wifi connections, seems irrelevant. I'm marking this bug confirmed, as instructed by the Kernel Bot.