ecryptfs-recover-private mounts in /tmp but does not decrypt

Bug #1028532 reported by Franck on 2012-07-24
This bug affects 6 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Jason Xing

Bug Description

Trying to recover a private home from a live CD. I know the mount passphrase.

So here is what happen :

1) sudo ecryptfs-recover-private /media/mydiskhomepartition/myuser
2) asked for passphrase, type in, success reported
3) directory is mount via ecryptfs in /tmp/ecryptfs.xxxxx , but ls on the /tmp/ecryptfs.xxxxx only shows Access-Your-Private-Data.desktop and README.txt

Expected result : access to my ex-home content.

some output :

root@ubuntu:~# ecryptfs-recover-private /media/479b31a7-5579-4e13-8693-595c1e58c567/franck/
INFO: Found [/media/479b31a7-5579-4e13-8693-595c1e58c567/franck/].
Try to recover this directory? [Y/n]:
INFO: Could not find your wrapped passphrase file.
INFO: To recover this directory, you MUST have your original MOUNT passphrase.
INFO: When you first setup your encrypted private directory, you were told to record
INFO: your MOUNT passphrase.
INFO: It should be 32 characters long, consisting of [0-9] and [a-f].

Enter your MOUNT passphrase:
INFO: Success! Private data mounted read-only at [/tmp/ecryptfs.6QzYM1XX].

root@ubuntu:~# mount
/cow on / type overlayfs (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
/dev/sr0 on /cdrom type iso9660 (ro,noatime)
/dev/loop0 on /rofs type squashfs (ro,noatime)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
gvfs-fuse-daemon on /home/ubuntu/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ubuntu)
/dev/sdb1 on /media/coffre type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc1 on /media/e8dbc16b-36af-47a3-9282-62035f345455 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc6 on /media/479b31a7-5579-4e13-8693-595c1e58c567 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/media/479b31a7-5579-4e13-8693-595c1e58c567/franck on /tmp/ecryptfs.6QzYM1XX type ecryptfs (ro,ecryptfs_sig=487ff62ab1955203,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

(see last mount point)

root@ubuntu:~# ls /tmp/ecryptfs.6QzYM1XX/
Access-Your-Private-Data.desktop README.txt

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
kenden (kenden) wrote :

After the prompt:
Enter your MOUNT passphrase:
I can type anything I want, and I will always get
"INFO: Success! Private data mounted read-only...."

So it is correct that the data be not decrypted. What is incorrect is the message "Success!"
It should be an error "incorrect passphrase" instead.

Dustin Kirkland  (kirkland) wrote :

Committed revision 823.

Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Fix Committed
importance: Undecided → Low
assignee: nobody → Dustin Kirkland  (kirkland)
dancing (dancingmusic) wrote :

I changed my user name at some point, without knowing that an encryption process might include the username. There was no notice. I followed all the de-crypt steps and was able to get "Success!" and a private folder with all the files, but still encrypted. I was able to copy them to an external drive.
Is the username utilized in the ecrypt process? If so, please post a notice. (There was a reason I changed the username. I was not able to log on--I kept getting the login screen back. Two years later it just started happening with my laptop as well, so I just filed a bug on that problem.)

Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

This bug was fixed in the package ecryptfs-utils - 104-0ubuntu1

ecryptfs-utils (104-0ubuntu1) trusty; urgency=low

  [ Colin King ]
  * src/libecryptfs/ecryptfs-stat.c, tests/kernel/extend-file-
    random/test.c, tests/kernel/inode-race-stat/test.c,
    - Fixed some 32 bit build warnings
  * src/libecryptfs/decision_graph.c, src/libecryptfs/key_management.c,
    src/libecryptfs/main.c, src/libecryptfs/module_mgr.c, src/utils/io.c,
    src/utils/mount.ecryptfs_private.c, tests/kernel/inotify/test.c,
    tests/kernel/trunc-file/test.c, tests/userspace/wrap-unwrap/test.c:
    - Fixed a pile of minor bugs (memory leaks, unclosed file descriptors,
      etc.) mostly in error paths
  * src/key_mod/ecryptfs_key_mod_passphrase.c, src/libecryptfs/main.c,
    - more Coverity fixes, memory leak, error checking, etc.

  [ Nobuto MURATA ]
  * fix an empty update-notifier window (LP: #1107650)
    - changes made in Rev.758 was incomplete

  [ Tyler Hicks ]
  * doc/manpage/ecryptfs.7:
    - adjust man page text to avoid confusion about whether the interactive
      mount helper takes a capital 'N' for the answer to y/n questions
      (LP: #1130460)
  * src/utils/ecryptfs_rewrap_passphrase.c:
    - Handle errors when interactively reading the new wrapping passphrase
      and the confirmation from stdin. Fixes a segfault (invalid memory read)
      in ecryptfs-rewrap-passphrase if there was an error while reading either
      of these passphrases.
    - Set AM_CPPFLAGS to always include config.h as the first include file.
      Some .c files correctly included config.h before anything else. The
      majority of .c files got this wrong by including it after other header
      files, including it multiple times, or not including it at all.
      Including it in the AM_CPPFLAGS should solve these problems and keep
      future mistakes from happening in new source files.
    - Enable large file support (LFS) through the use of the AC_SYS_LARGEFILE
      autoconf macro. ecryptfs-utils has been well tested with LFS enabled
      because ecryptfs-utils is being built with
      '-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' in Debian-based distros.
      This is mainly needed for some of the in-tree regression tests but
      ecryptfs-utils, in general, should be built with LFS enabled.
  * debian/rules:
    - Don't append '-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' to the CFLAGS
      now that the upstream build enables LFS
  * tests/userspace/, tests/userspace/lfs/test.c:
    - Add a test to verify that LFS is enabled. This test is run under the
      make check target.
  * tests/kernel/enospc/test.c:
    - Fix test failures on 32 bit architectures due to large file sizes
      overflowing data types

  [ Dustin Kirkland ]
  * src/utils/ecryptfs-setup-swap: LP: #1172014
    - write crypttab entry using UUID
  * src/utils/ecryptfs-recover-private: LP: #1028532
    - error out, if we fail to mount the private data correctly

  [ Colin King and Dustin Kirkland ]
  *, src/daemon/main.c, src/libecryptfs/cmd_ln_parser.c,


Changed in ecryptfs-utils (Ubuntu):
status: Fix Committed → Fix Released
Bertrand Mathieu (bmat) wrote :

I have exactly the same problem as described in original bug report, and I am using 14.04 with ecryptfs-utils - 104-0ubuntu1.

Setup information: my home folder is fully encrypted.

I am attemping to mount from a btrfs read-only snapshot. My home folder is mounted (using normal OS, not a live CD; I just want to retrieve an old version of a file).

I run command from /path/to/home/snapshot/.ecryptfs/me, since symlinks in /path/to/home/me are targeted at "/home/.ecryptfs/me".

I know the valid passphrase, given by ecryptfs-unwrap-passphrase.

I can type anything when asked by ecrypt-recover-private, it will pretend it is a success, the mount is listed by "mount" command, but the mounted folder has nothing decrypted, it's like it is a simple link to original ecrypt folder.

Martin (martin-kammerlander-3) wrote :

I'm having the same issues too. Tried to get the passphrase like this:

 $ sudo ecryptfs-unwrap-passphrase /media/USERNAME/763e56fe-cce3-4fe6-ab5d-50426cbd408e/home/USERNAME/.ecryptfs/wrapped-passphrase

and then trying to unlock like:
$ cd /media/USERNAME/763e53fe-cce3-4fe6-ab5d-50426cbd408e/home/nutella
$ sudo ecryptfs-recover-private .
INFO: Found [.].
Try to recover this directory? [Y/n]: Y
INFO: Could not find your wrapped passphrase file.
INFO: To recover this directory, you MUST have your original MOUNT passphrase.
INFO: When you first setup your encrypted private directory, you were told to record
INFO: your MOUNT passphrase.
INFO: It should be 32 characters long, consisting of [0-9] and [a-f].

Enter your MOUNT passphrase:
INFO: Success! Private data mounted at [/tmp/ecryptfs.V6lfkUV1].

And then I only see the same files as if it would not have been decrypted.

Richard C (richard-c) on 2015-03-08
tags: added: utopic
no longer affects: ecryptfs
paroxyzm (paroxyzm) wrote :

I surely affects me...

Patrick (pjw91) wrote :

This affects me, too.

Jason Xing (wlxing) wrote :

Could you guys give more information on how you do to ecryptfs-recover-private command, not just say "affects me" and stuff? BTW, I tested on Ubuntu Precise and Trusty very well.

Jason Xing (wlxing) wrote :

My apologize. It works successfully when I enter the wrong mount passphrase.
However, it doesn't need to be fixed really. When we mount eCryptfs, we also could enter different passphrases and decrypted certain files. It's the design of eCryptfs, I think.

One thing we're supposed to do is to display the warning/information like "Mount successfully. But maybe the mount passphrase is not the key to decrypt your private data".

What do you say about this? Any information are welcome!


Jason Xing (wlxing) wrote :

I read the patch written by Dustin recently. It just test whether the mount command works successfully or not, not give the warning "It may not decrypt your private data". I'm going to reassign this to me.

Jason Xing (wlxing) on 2017-05-29
Changed in ecryptfs-utils (Ubuntu):
assignee: Dustin Kirkland  (kirkland) → Jason Xing (wlxing)
assignee: Jason Xing (wlxing) → nobody
assignee: nobody → Jason Xing (wlxing)
Jason Xing (wlxing) wrote :

I reopened a bug report at bug 1694272.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers