eCryptfs

32bit vs 64bit incompatibility

Bug #682654 reported by JensLechtenboerger
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eCryptfs
In Progress
High
Unassigned

Bug Description

I have been using ecryptfs for some time on 32 bit versions of Ubuntu (I think I started with 9.04 and had no problems through 10.10) with reiserfs: aes with "16" for "key bytes" and filename encryption, no plaintext passthrough
Let's say ecryptfs-manager and "sudo mount -t ecryptfs" reported a ecryptfs_sig and ecryptfs_fnek_sig of X for my passphrase.
I switched to the 64 bit version of Ubuntu 10.10 with ext4. For my passphrase, ecryptfs-manager now reports a different signature Y, "sudo mount -t ecryptfs" fails, and dmesg shows lots of messages:
Could not find key with description: [X]
[ 88.926191] process_request_key_err: No key
[ 88.926192] ecryptfs_parse_tag_70_packet: Error attempting to find auth tok for fnek sig [X]; rc = [-2]
[ 88.926194] ecryptfs_decode_and_decrypt_filename: Could not parse tag 70 packet from filename; copying through filename as-is

If I choose "32" for "key bytes", then my old signature X is displayed again, yet mount fails: Error mounting eCryptfs: [-22] Invalid argument
dmesg says: Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities

Finally, I tried to add the new signature Y to an entry in /etc/fstab to use ecryptfs-manager with "mount -i". This fails as well (which I expected). Mount and dmesg do not report a problem, yet the directory contains garbled filenames, which I cannot access.

How can I access my files on a 64 bit system?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 682654] [NEW] 32bit vs 64bit incompatibility

I suspect you'll want to use ecryptfs-wrap-passphrase. As a first
test and workaround, please do

 ecryptfs-add-passphrase

and type in the mounting passphrase. Then try mounting the filesystem.

Revision history for this message
JensLechtenboerger (lechten) wrote :

That works if I start in a clean state (without ecryptfs-manager or after "keyctl clear @u"). What's happening here?

Thanks
Jens

Revision history for this message
JensLechtenboerger (lechten) wrote :

That was too fast. Today, ecryptfs-add-passphrase did not work (gave the wrong signature). Afterwards, I tried ecryptfs-manager, which then gave the correct signature.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Did you give ecryptfs-add-passphrase the fs passphrase, or the wrapping (i.e. perhaps
your login) passphrase? Do I understand right that you're saying that yesterday
ecryptfs-add-passphrase gave the right signature, and today it gave the wrong one?

Revision history for this message
JensLechtenboerger (lechten) wrote :

I'm booting directly into my user session without login password. The passphrase for ecryptfs is different from my login password.
I had some trouble reproducing the problem after rebooting: Both, ecryptfs-add-passphrase and ecryptfs-manager produced the correct signature.
However, after executing "sudo ls" (your question concerning the password made me try this), both produced the incorrect signature. After several retries, with "keyctl clear @u" in between, ecryptfs-manager gave the correct signature. I don't see why and when...

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 682654] Re: 32bit vs 64bit incompatibility

Quoting JensLechtenboerger (<email address hidden>):
> I'm booting directly into my user session without login password. The passphrase for ecryptfs is different from my login password.
> I had some trouble reproducing the problem after rebooting: Both, ecryptfs-add-passphrase and ecryptfs-manager produced the correct signature.
> However, after executing "sudo ls" (your question concerning the password made me try this), both produced the incorrect signature. After several retries, with "keyctl clear @u" in between, ecryptfs-manager gave the correct signature. I don't see why and when...

Interesting - can you reliably reproduce this, that if you do:

 log in
 sudo ls
 ecryptfs-add-passphrase

it produces the incorrect signature? If so, then that's something more
concrete to follow up on.

Revision history for this message
JensLechtenboerger (lechten) wrote :

Exactly:
 Boot (with automatic log in)
 sudo ls
 ecryptfs-add-passphrase
produces the incorrect signature.

However, today I also get an incorrect signature after boot if I omit the "sudo ls".
There's more: A minute (or so) after boot I get a popup window claiming that my Ubuntu One storage is full (I used Ubunto One in the past, but stopped and didn't configure it on my new machine). If I do
 Boot
 Wait for popup window
 ecryptfs-add-passphrase
then I get the correct signature.

I also see the following:
Boot
 ecryptfs-add-passphrase with incorrect signature
 Wait for popup window
 ecryptfs-add-passphrase with incorrect signature
 sudo ls
 ecryptfs-add-passphrase with correct signature

Dustin Kirkland  (kirkland)
Changed in ecryptfs:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hmm, okay, this is very strange. I suspect that you have a couple of different issues happening here.

I'll do a bit of 32bit/64bit testing again, but I've tested this previously, and I was able to move files and passphrases back and forth between 32bit and 64bit Ubuntu systems and read/write them without a problem.

Revision history for this message
JensLechtenboerger (lechten) wrote :

Just to let you know: I'm still having problems mounting my directory on Ubuntu 10.10. Frequently, the incorrect signature is reported. Then I just retry ecryptfs-add-passphrase until the correct one is reported. I don't see any pattern when or why the command fails or succeeds.

Dustin Kirkland  (kirkland)
Changed in ecryptfs:
importance: Medium → High
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Okay, I'm getting my head wrapped around this. I think you have a bad configuration somewhere. I think it's your "sudo ls" step that's actually working around your configuration problem. The "sudo ls" prompts you for your login passphrase right? The one that you *didn't* enter when you auto-logged-into the system right?

Can you try this ...

1) fresh boot
2) ecryptfs-insert-wrapped-passphrase-into-keyring

Also, can you verify that the contents of $HOME/.ecryptfs/* and /home/.ecryptfs/$USER/.ecryptfs/* are absolutely PERFECTLY identical?

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I suspect that you've got more than one wrapped-passphrase file on your system, with different contents.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Also, list your keyring just after your 'sudo ls', but before your ecryptfs-add-passphrase. Use 'keyctl list @u'.

I suspect that the 'sudo ls' is actually loading the correct keys into your keyring. It's when it prompts you for your login passphrase that it correctly decrypts your wrapped passphrase and enters it into your keyring. I suspect that whatever you're entering at the ecryptfs-add-passphrase prompt is incorrect.

Revision history for this message
JensLechtenboerger (lechten) wrote :

Since my previous posting I've been unable to reproduce the problem.

Concerning your questions: I don't use a wrapped passphrase.
The directories $HOME/.ecryptfs/ and /home/.ecryptfs/ do not exist. There is /root/.ecryptfs, which is empty.
'keyctl list @u' reports 'keyring is empty' before and after 'sudo ls'.

Revision history for this message
Chew Jian Yue (chewjianyue) wrote :

Someone is fixing it, according to another post

Changed in ecryptfs:
status: Incomplete → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.