The currently recommended way of mounting files from cloud or backup

Hi Ted,

Well, yeah, just using the "mount" command should really work. You'd
need a long, and somewhat complex set of options, but that really
should work. That's all the helper really does, is load the necessary
keys, and execute the complex mount command for you.

I just did the following, which *should* work...

 1) While your encrypted homedir is mounted, do this:
  $ grep "$USER.*ecryptfs" /proc/mounts
 2) Record the options, like this:
/home/kirkland/.Private on /home/kirkland type ecryptfs
(ecryptfs_sig=<xxx>,ecryptfs_fnek_sig=<yyy>,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
 3) Log out as your user, and clear your keyring
 4) Log back in as a different user (or as root)
 5) Manually load your long, random mount passphrase into this user's
keyring with:
  $ ecryptfs-add-passphrase --fnek
 6) Check your keyring, make sure both of your signatures are show
  $ keyctl list @u
 7) Then just do the mount
  $ sudo mount -t ecryptfs
sudo mount -t ecryptfs -o
rw,relatime,ecryptfs_fnek_sig=<xxx>,ecryptfs_sig=<yyy>,ecryptfs_cipher=aes,ecryptfs_key_bytes=16
/home/kirkland/.Private /mnt

That fails for me :-( Which means there's a bug in the mount program
somewhere. I need to get this fixed for Lucid.

:-Dustin

Hey Dustin

I'm glad you said that, because I was having problems too (using 9.10) and couldn't see where I was going wrong. In my case, I got some of the filenames back properly when I did a listing in the terminal, but in Nautilus there were just a handful (and less than shown in terminal) of un-decrypted files, even with "Show hidden files" enabled.

Let me know if I can do any tests to help track bug.

PS...I realise Linux is Linux, but Ubuntu is making headway into the global share of OS use due to it's ability at making Linux tasks easier for the standard user. Even when the above bug is fixed, this is still quite a complex way of simply gaining access to your files again in the event of a system failure, or perhaps even for accessing offsite backups (I, for one, often backup my work to my remote off-site server).

Most encryption software, like Truecrypt (as an example) is simply a case of saying "Mount that there, and the password is...". Is there any way eCryptfs could be simplified for restoration tasks without compromising its encryption prowess I wonder?

I will try this.

Dustin,

I think your script fails because in step 5) you add keys to the user's keyring, but the sudo'ed mount in step 7) looks for them in root's keyring. At least that's the impression I get from this snippet in mount.ecryptfs_private.c

  /* We must maintain our real uid as the user who called this
    * program in order to have access to their kernel keyring.
   * Even though root has the power to mount, only a user with
   * the correct key in their keyring can mount an ecryptfs
   * directory correctly.
   * Root does not necessarily have the user's key, so we need
   * the real uid to be that of the user.
   * And we need the effective uid to be root in order to mount.
   */
  setreuid(-1, 0);

Unfortunately, as far as I can tell, sudo has no provision for keeping the real uid while setting the effective uid to root.