The currently recommended way of mounting files from cloud or backup

Asked by Ted_Smith on 2010-03-13

Hi

I realise there are several ways to mount files encrypted with eCryptfs from one Ubuntu machine on another Ubuntu machine, though many of these methods seem somewhat tricky, and in many cases, only partially successfull (usually due to the difficulties users have following such techniques).

I have read the following threads in particular :

Most relevant:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/455709

Also:

https://bugs.launchpad.net/ecryptfs/+bug/381920
http://<email address hidden>/msg01479.html

The top link is fairly recent and suggests there might still be some issues with restoring files from a backup.

Dustin : In your entry dated 2009-10-20 in that top link you state your method of restoring files encrypted on one Ubuntu machine to another Ubuntu machine. Is that currently the best way of doing it, or are there other methods published somewhere else, or that are about to be announced\released?

Taking the scenario of Joe Bloggs who has used Ubuntu 9.10, and his computer suddenly stops working. He takes the computer to his local IT repair shop and tells them his login password and mount passphrase. They connect the disk to their own equipment and copy out the content of /home/.ecryptfs/joebloggs to their own Ubuntu machine. How best are they to mount it?

Thanks

Ted

Question information

Language:
English Edit question
Status:
Answered
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Last query:
2010-03-13
Last reply:
2010-03-13
Dustin Kirkland  (kirkland) said : #1

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

Ted_Smith (tedsmith28) said : #2

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.

Ted_Smith (tedsmith28) said : #3

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?

COKEDUDE (cokedude) said : #4

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.

Can you help with this problem?

Provide an answer of your own, or ask Ted_Smith for more information if necessary.

To post a message you must log in.