umount of ecryptfs does not automatically clear the keyring (can be mounted by root later)

[Jonathan Ernst]

How to reproduce :

1) setup a private directory
2)
sudo -s

cd /

mkdir source

mkdir target

cp ~user/.Private/example.pdf source

file /source/example.pdf
/source/example.pdf: data

mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

file /source/example.pdf
/source/example.pdf: PDF document, version 1.4

Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something.

============
SRU Justification:

Impact: This bug affects users of Ubuntu's encrypted home/private directory feature if they are concerned about a malicious or snooping root user on the system.

Minimal patch: The minimal patch can be found in upstream commit r520:
 * http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/520

Reproduce instructions: Follow the excellent instructions in this bug description.

Regression potential: Minimal. The key removal code is the last thing that happens before the umount is attempted. If for some reason the new key-unlinking code failed (it should not; errors are ignored; keys are removed on a best-effort basis), then the umount might not happen. As I said, this should be a near impossible situation. I think this update should be very safe. It's been in Natty now for a couple of weeks.
============

[Dustin Kirkland  (kirkland)]

This is probably due to kernel keyring caching.

After doing your unmount, do the following to clear your kernel keyring:
 $ keyctl clear @u

Then try to remount.

:-Dustin

[Denis (denis-redhat-bugs)]

Created attachment 329304
Text file of session to show commands used to reproduce problem

Description of problem:Any passphrase entered at mount will decrypt file

Version-Release number of selected component (if applicable):
ecryptfs-utils-61-0.fc10.i386
kernel-2.6.27.9-159.fc10.i686

How reproducible:Entering a wrong passphrase will decrypt file

Steps to Reproduce:
1.As root, mount directory using ecryptfs
2.put file in directory
3.umount directory
4.mount directory again with wrong passphrase
5.file can be retrieved

Actual results: file can be retrieved

Expected results:should not be able to read file if wrong passphrase is entered at mount

Additional info: Everything works as expected on FC9. Giving wrong passphrase during mount gives the error "Input/output error" when trying to access crypted file.

[Eric (eric-redhat-bugs)]

I think this is a feature, not a bug.

The first passphrase ended up cached in your kernel crypto keychain, and so was still available to decrypt your old files. If you wish to clear it, use keyctl.

Other users will not be able to see these files by entering arbitrary passphrases.

-Eric

[Denis (denis-redhat-bugs)]

Hi Eric,

Thanks a lot for the explanation. I played with keyctl and now see what is going on.
However, this automatic caching leads to a false sense of security. Whatever strength I use for the crypted FS key (30+ characters), the overall security is only as strong as my (8 to 10 character) password. And I don't get any warning of this fact.

Is there a way to disable this automatic caching?
Until I understand more completely the whole process, it seems I must do an alias on the umount command to be immediately followed by "keyctl clear @u" command.

Thank you very much for the time you spent on this.

[Michal (michal-redhat-bugs)]

Hi,

I've talked about this with upstream with this conclusions:

1) it's not a bug, it's a feature. Even gnome-keyring doesn't clear out a key after an application uses it

2) If you want to clear your keyring, use `keyctl clear @u`

3) the password at mount time is not a password to read existing files. It is a password that is turned into a key which is used when creating new files

4) there will be added new mount option that will automatically clear keyring after umount (so mount with wrong passphrase will not work any more)

[Dustin Kirkland  (kirkland)]

Actually, I have a reasonable solution to this problem...

I'm going to add the keyctl keyring clearing to the ecryptfs-umount-private shell script wrapper.

The recommended mechanism for unmounting your private data AND clearing your keyring of the relevant keys will be to use the helper:
 $ ecryptfs-umount-private

Working on this at the moment...

:-Dustin

[Dustin Kirkland  (kirkland)]

I have committed a partial fix, will be in the -69 release.

See:
 * http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=1abdd21606f764382f2abc8a73abda091ace76fd

This will clear the keyring of the relevant keys in the encrypted home/encrypted private case (ie, if you're using our helpers).

Otherwise, you need to clear your keyring with "keyctl clear @u", or prune out particular key(s) with "keyctl unlink $FOO @u".

Tyler has mentioned a possibility of solving this with an umount.ecryptfs helper, as an option. As such, I'm going to leave this upstream bug open, and assign it to him.

:-Dustin

[Launchpad Janitor (janitor)]

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

---------------
ecryptfs-utils (69-0ubuntu1) jaunty; urgency=low

  * New upstream release, dropped all patches (included upstream)
  * This release includes support for filename encryption (LP: #264977)
  * This release promotes keyutils from a 'recommends' to a 'depends,
    for access to the keyctl command, which is used by the helper scripts
    to clear the keyring on unmount (LP: #313812)

 -- Dustin Kirkland <email address hidden> Mon, 26 Jan 2009 13:51:21 -0500

[Denis (denis-redhat-bugs)]

Thanks for the precisions.
Item 3) makes it very clear and 4) will be a welcome enhancement.
Thanks again.

[Michal (michal-redhat-bugs)]

extract from irc:
> let me answer this question a different way, "when is this an actual problem?"
> first, only a root user can perform an ecryptfs mount
> non-root users can perform mounts through the setuid binary, mount.ecryptfs_private, but in that case, what they can do is tightly constrained
> to perform a generic mount, it has to be a root user
> now, for this to be a problem, the *root* user must:
> a) establish an ecryptfs mount with one passphrase
> b) unmount
> c) do *not* clear the keyring
> d) do *not* logout of the session
> and then a malicious user must obtain access to *that* session
> by either sitting down at the terminal, or accessing via vnc or screen or some such
> at that point, the malicious user has a root shell
> and while accessing some encrypted data is a bad thing, there are a lot of bad things that can happen at that point
> so we can help with (c) by clearing the keys on unmount
> but ultimately, (d) is the biggie ... the root user needs to logout of the session if they want their data protected

so I think you can still feel yourself safe :)

anyway, there is still plan to add new feature mentioned before

[Denis (denis-redhat-bugs)]

Hi Michael,

Thanks for your follow-up.
At least on my system (Fedora 10), "the biggie" point d) is not true.

I am logged in as a normal user, I issue a "su" command, mount the ecrypted FS as root with the valid password. Then I umount, exit out of the "su" command and even logout the normal user. (No one is now logged on to the system.)

I log again with my normal user account, do a "su" and mount the ecrypted FS with another password. The file is unencrypted again.

In other words, only a `keyctl clear @u` or a reboot will clear the key. That is more frightening.

I think that even without the new added feature, documenting the fact as clearly as you did in your email of the 26th would go a long way toward eliminating a false sense of security when using the ecryptfs.

Thanks a lot

[Tyler Hicks (tyhicks)]

This patch creates a new eCryptfs umount helper that looks in the mount options for ecryptfs_unlink_sigs. If that option is found, it will determine the ecryptfs_sig and the ecryptfs_fnek_sig, if one exists, and unlink those auth toks from the user keyring. If the ecryptfs_unlink_sigs option is not detected, a normal umount will occur.

This will not affect users who have pre-existing fstab entries and are not expecting their keys to unlinked at umount.

[Dustin Kirkland  (kirkland)]

Branch merged, committed upstream. Will be in release 70.

:-Dustin

[Dustin Kirkland  (kirkland)]

Fixed in ecryptfs-utils-70.

:-Dustin

[Michal (michal-redhat-bugs)]

this feature has been added into ecryptfs-utils v. 70

you can add ecryptfs_unlink_sigs mount option that clears your keyring during umount

[Tyler (tyler-redhat-bugs)]

It should also be noted that the eCryptfs mount helper adds ecryptfs_unlink_sigs to the mount options by default now.

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Fedora (fedora-redhat-bugs)]

ecryptfs-utils-70-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

[Piergiorgio (piergiorgio-redhat-bugs)]

Is this really fixed?
With the automount of ~/Private I got a similar problem.

Specifically:
1) log in with a user having the ~/Private thing
2) log out
3) as root change to user (su - user)

Then, without asking for password of course, ~/Private is mounted.

Does this belong to this bug or should I open a new one?

Thanks,

piergiorgio

[Michal (michal-redhat-bugs)]

(In reply to comment #11)
> Is this really fixed?

Yes and no :)

* "add umount option to clear per-user keyring"
- is done, there is new mount option and it works - it's mount option so it works if you add it to mount -t ecryptfs .... -o ecryptfs_unlink_sigs,...

* clear per-user keyring with ecryptfs-(u)mount-private (or auto mount after login) doesn't work *yet* = in version 70

I'll let you know in this bz when working version is released (it'll be v. 72 I guess)

[Michal (michal-redhat-bugs)]

(In reply to comment #12)
> I'll let you know in this bz when working version is released (it'll be v. 72 I
> guess)

unfortunately, released version 73 still doesn't contain the fix...

[Tyler Hicks (tyhicks)]

Reopening this bug. Dustin and Michal are both reporting that the unlinking doesn't work from PAM.

We could put some code in umount.ecryptfs_private to do the unlinking, but since that is a setuid binary in most/all distros, lets keep it simple.

We shouldn't have umount.ecryptfs_private execute umount.ecryptfs because that isn't keeping it simple *and* umount.ecryptfs will be executed as root, making it difficult/impossible to unlink the user's keys.

This functionality should go into the kernel.

[Dustin Kirkland  (kirkland)]

Okay, I'm not totally clear on what's left to this bug.

What I really need (Michal, Tyler) is a clear reproduce case.

Here's what I've tested ...

 1) user "foo" has an encrypted home directory, logs in, is able to read/write his home data
 2) user "foo" logs out of all open sessions, and his home directory is unmounted
 3) in my testing, that user's key is cleared; i can't find any evidence of it still hanging around
 4) at this point, i can login as root, i can't see the keyring for "foo", i can su - foo, but his key is not available
 5) as root, if foo's key is not available, and ~foo is not mounted, I cannot see any of foo's data

This is all "as expected" as far as I can tell. Can you guys please clarify the vector by which the key is still exposed?

:-Dustin

[Dustin Kirkland  (kirkland)]

Michal Hlavinka, ping? Can you clarify what still needs to be done here, from your perspective?

:-Dustin

[Michal Hlavinka (mhlavink)]

how to reproduce:
1) su -
2) useradd ecryptfstest
3) passwd ecryptfstest #add any passphrase
4) logout root
5) log in as ecryptfstest
6) ecryptfs-setup-private
7) log out and log in
8) mount # confirm ~/Private is mounted
9) log out
10) mount # confirm ~/Private is not mounted
11) su -
12) su - ecryptfstest

result:
~/Private is mounted (no passphrase was entered - because key is still in keyring)

expected:
~/Private is not mounted (key not in keyring)

in short: after logout, key is not removed from keyring

[Dustin Kirkland  (kirkland)]

Okay, using Michal's latest reproduce instructions, I do see this issue with the latest ecryptfs-utils-75.

I'll try to solve this in pam_ecryptfs. Basically, we need to duplicate the functionality of the /usr/bin/ecryptfs-umount-private shell script. We'll need to check the return code of the umount.ecryptfs_private execution, and if that succeeds, loop through the keys in Private.sig and unlink each one.

:-Dustin

[Dustin Kirkland  (kirkland)]

Let me summarize where we're at...

This is complicated because of reference counting. We should never clear these keys if they are in use elsewhere.

We have gone through great pains to handle this counting properly in umount.ecryptfs_private. Thus, we need to leverage thank. If, and only if, the umount actually succeeds should we clear these keys.

From my perspective, this can only happen in two places:
 1) pam_ecryptfs, by checking the return code of the umount.ecryptfs_private call
 2) umount.ecryptfs_private, *after* doing the unmount

I'm hoping to get this solve by karmic.

:-Dustin

[Dustin Kirkland  (kirkland)]

With the help of David Howells here at LCA2010, I actually have a working fix for this.

There's a couple of moving pieces. There's a minor patch to pam_keyinit.so, a small patch to ecryptfs-utils using the session keyring, rather than the user keyring, and adding pam_keyinit.so in the proper places in the pam stack (I think Fedora already has it, however, SELinux might cause some problems).

Stay tuned, I'll commit a fix once I'm satisfied with my testing.

:-Dustin

[Dustin Kirkland  (kirkland)]

Okay, so I can't quite commit the fix yet, as there's some controversy about it.

However, I want to attach the patches here so that they don't get lost.

In the current solution, there's two small patches.

Basically, instead of loading the keys into the User keyring, we should load them into the Session keyring. The session keyring is automatically cleared on logout, whereas the User keyring hangs around.

To do this, we need a minor patch to pam adding a couple of stubs for pam_keyutils, and we need to modify key_management.c and mount.ecryptfs_private.c to work with the session keyring. All in all, two simple patches.

However, when I asked Steve Langasek to review the pam code, he suggested that pam_ecryptfs should be doing its work in pam session, rather than pam authenticate. As such, the current patches are not acceptable. It's a fair amount of work (and a *lot* of testing) to move the pam_ecryptfs code around. Not impossible, will just take some time.

[Dustin Kirkland  (kirkland)]

First patch to pam...

[Dustin Kirkland  (kirkland)]

Second patch to ecryptfs...

[Tyler Hicks (tyhicks)]

Dustin, I realize those patches are not in finished form, but it looks like the changes to ecryptfs_add_auth_tok_to_keyring() will cause a regression in the case of non-pam initiated eCryptfs mounts. I don't think we want auth toks for those types of mounts to be specific to any session. Also, the keyring variable should technically be of type key_serial_t.

Do you know what is going on in ecryptfs_validate_keyring() when KEY_SPEC_SESSION_KEYRING is being linked to KEY_SPEC_USER_KEYRING? Isn't that essentially the same thing as what your patch is doing with the first call to add_key() in ecryptfs_add_auth_tok_to_keyring()?

[Serge Hallyn (serge-hallyn)]

Quoting papukaija (<email address hidden>):
> ** Tags added: jaunty karmic lucid maverick patch
>
> --
> umount of ecryptfs does not automatically clear the keyring (can be mounted by root later)
> https://bugs.launchpad.net/bugs/313812
> You received this bug notification because you are a member of eCryptfs
> Developers, which is subscribed to eCryptfs.
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Triaged
> Status in “ecryptfs-utils” package in Ubuntu: Confirmed
> Status in “ecryptfs-utils” source package in Lucid: Confirmed
> Status in “ecryptfs-utils” source package in Maverick: Confirmed
> Status in “ecryptfs-utils” source package in Jaunty: Confirmed
> Status in “ecryptfs-utils” source package in Karmic: Confirmed
> Status in “ecryptfs-utils” package in Fedora: Fix Released
>
> Bug description:
> How to reproduce :
>
> 1) setup a private directory
> 2)
> sudo -s
>
> cd /
>
> mkdir source
>
> mkdir target
>
> cp ~user/.Private/example.pdf source
>
> file /source/example.pdf
> /source/example.pdf: data
>
> mount -t ecryptfs source target
> Passphrase: type anything that is not your passphrase or passwords
> Select cipher:
> 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
> 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
> 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
> 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
> 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
> 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
> Selection [aes]:
> Select key bytes:
> 1) 16
> 2) 32
> 3) 24
> Selection [16]:
> Enable plaintext passthrough (y/n) [n]: n
> Attempting to mount with the following options:
> ecryptfs_key_bytes=16
> ecryptfs_cipher=aes
> ecryptfs_sig=4c748f746abcc24e
> WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
> it looks like you have never mounted with this key
> before. This could mean that you have typed your
> passphrase wrong.
>
> Would you like to proceed with the mount (yes/no)? yes
> Would you like to append sig [4c748f746abcc24e] to
> [/root/.ecryptfs/sig-cache.txt]
> in order to avoid this warning in the future (yes/no)? no
> Not adding sig to user sig cache file; continuing with mount.
> Mounted eCryptfs
>
> file /source/example.pdf
> /source/example.pdf: PDF document, version 1.4

But you're not just logging in as root. You're using sudo which will keep
your keyrings and much of your environment from your user shell. Try the
following instead:

Create a new user. After doing the ecryptfs unmount, 'switch user' (leave
your original user logged in) to the new user, and sudo from that new user.
Then try the ecryptfs mount from that shell. Does it still work?

> Now I know that the files are really encrypted (using a wrong passphrase on
> files copied to another computer makes the file unreadable), but I don't
> understand how root on my system can mount my files without the correct
> passphrase... is the passphrase stored somewhere? This is really strange and
> doesn't give me too much confidence i...

[papukaija (papukaija)]

@Serge: I haven't submitted this bug or not even commented on it so why did you write "Quoting papukaija" ? I only added some tags to this bug report and nothing else.

[Serge Hallyn (serge-hallyn)]

Quoting papukaija (<email address hidden>):
> @Serge: I haven't submitted this bug or not even commented on it so why
> did you write "Quoting papukaija" ? I only added some tags to this bug
> report and nothing else.

Sorry, my mail client added that.

[Romualdo Caruso (aldo-caruso)]

The following effect may be a consequence of the same bug.

Distribution: Ubuntu 10.04

1) Create user1 ( with administrative privileges )
2) Create user2 ( without administrative privileges )
3) Logged as user2 set up a private directory, logout & login, create some files in ~/Private, logout.
4) Logged as user1 change user2 password.
5) Logged as user2 (using the new password defined by user1) you can access the /home/user2/Private directory and its contents.

The effect persists until you reboot.

Conclusion:
A privileged user can access private data from others (who recently have logged in and out ) by means of changing their password.

[Dave Walker (davewalker)]

Has this stalled? Is anybody actively looking for a resolution to this issue?

[Dustin Kirkland  (kirkland)]

On Fri, Aug 13, 2010 at 7:42 AM, Dave Walker <email address hidden> wrote:
> Has this stalled? Is anybody actively looking for a resolution to this
> issue?

I'm not currently looking at it.

I have a working solution that requires two minor, empty stubs added
to PAM, and a small patch to eCryptfs. The PAM hooks were rejected.
I haven't had the drive to push harder on that, or look for a
different solution.

[Romualdo Caruso (aldo-caruso)]

More side effects working with encrypted homes:

1) The same side effect explained above between user1 and user2 happens if user2 is a privileged user and if user2 has his home directory encrypted.

2) If you have your home encrypted, accessing remotely with ssh is not possible if you demand using private & public keys (setting PasswordAuthentication = no in the file /etc/ssh/sshd_config ), because the sshd daemon has to access ~/.ssh/authorized_keys file in a directory which is not yet mounted.

IMHO, home directory encryption is still unreliable and it should be userd with care. In its current state, it only protects after rebooting the machine ( please tell me if this observation is wrong ), and consequently only protects from a disk or machine physical theft.

[Serge Hallyn (serge-hallyn)]

@Dustin,

is there any reason why we can't simply use the same fix as is being used in mount.ecryptfs.c, in mount.ecryptfs_private.c?

[Dustin Kirkland  (kirkland)]

Okay, fixed this once and for all in r520!

Big thanks to Tyler and Serge for helping find a suitable approach (and believe me, I have spent several days trying several different approaches).

So the current fix modifies the setuid umount.ecryptfs_private helper. We can't do it in umount.ecryptfs, because this runs as root, and root can't unlink the non-root user's keys (at least not with the existing implementation). But if we do it in the umount.ecryptfs_private helper, we can do it as the user before doing the setuid(0) and calling the unmount. Note that the failure to unlink the keys is a non-fatal error. A suitable message (and a pointer to how to unlink keys correctly) is shown on stderr, but the unlink proceeds. Doing this here is quite nice, as it allows us to use the reference counting code, etc, and only unlink when there are no other open references to the mount.

This will be released in ecryptfs-utils-85.

[Dustin Kirkland  (kirkland)]

Let's give this a week or two in Natty Alpha2, and then we can put together an SRU for Karmic/Lucid/Maverick.

[Launchpad Janitor (janitor)]

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

---------------
ecryptfs-utils (85-0ubuntu1) natty; urgency=low

  [ Dustin Kirkland ]
  * src/utils/ecryptfs-recover-private: clean sigs of invalid characters
  * src/utils/mount.ecryptfs_private.c:
    - fix bug LP: #313812, clear used keys on unmount
    - add ecryptfs_unlink_sigs to the mount opts, so that unmounts from
      umount.ecryptfs behave similarly
    - use ecryptfs_remove_auth_tok_from_keyring() on the sig and sig_fnek

  [ <email address hidden> ]
  * src/utils/ecryptfs-migrate-home:
    - support user databases outside of /etc/passwd, LP: #627506
 -- Dustin Kirkland <email address hidden> Sun, 19 Dec 2010 10:50:52 -0600

[Dustin Kirkland  (kirkland)]

Howdy,

I just prepared a round of SRUs to fix this bug in Karmic, Lucid, and Maverick.

I would really appreciate if some of the people suffering from this bug could test out the proposed packages as soon as they're accepted and built.

Cheers!
Dustin

[Martin Pitt (pitti)]

Accepted ecryptfs-utils into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Martin Pitt (pitti)]

Rejecting uploaded maverick update:

FAILED: ecryptfs-utils (The source ecryptfs-utils - 83-0ubuntu3.1 is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)

Please reupload with fixed version number.

[Martin Pitt (pitti)]

Accepted ecryptfs-utils into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[C de-Avillez (hggdh2)]

Confirmed fixed for Lucid, ecryptfs-utils 83-0ubuntu3.1.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 83-0ubuntu3.1

---------------
ecryptfs-utils (83-0ubuntu3.1) lucid-proposed; urgency=low

  * Cherry pick upstream bzr commit r520
  * src/utils/mount.ecryptfs_private.c:
    - fix bug LP: #313812, clear used keys on unmount
    - add ecryptfs_unlink_sigs to the mount opts, so that unmounts from
      umount.ecryptfs behave similarly
    - use ecryptfs_remove_auth_tok_from_keyring() on the sig and sig_fnek
 -- Dustin Kirkland <email address hidden> Fri, 11 Feb 2011 17:21:59 -0600

[Martin Pitt (pitti)]

Setting back to v-needed for karmic/maverick.

[Martin Pitt (pitti)]

This package has been in karmic-proposed for a long time without verification. I removed it as karmic is end-of-life now.

[Marc Deslauriers (mdeslaur)]

This has been in maverick-proposed for 22 weeks now. Could someone test it, please.

[C de-Avillez (hggdh2)]

Verified for Maverick:

Welcome to the Ubuntu Server!
 * Documentation: http://www.ubuntu.com/server/doc
Last login: Thu Jul 28 14:41:12 2011
root@ubuntu:~# mount
/dev/vda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

# ubuntu has not logged in since boot:

root@ubuntu:~# ls /home/ubuntu
Access-Your-Private-Data.desktop README.txt

# ubuntu logged in on another pseudo terminal:

root@ubuntu:~# mount | grep ubuntu
/home/ubuntu/.Private on /home/ubuntu type ecryptfs (ecryptfs_sig=5cb83cfa021dc74e,ecryptfs_fnek_sig=bb92820c0e6e63ad,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

# ubuntu logged off:

root@ubuntu:~# mount | grep ubuntu
root@ubuntu:~# su - ubuntu
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Verification successful.
ubuntu@ubuntu:~$ ls
Access-Your-Private-Data.desktop README.txt
ubuntu@ubuntu:~$

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Serge Hallyn (serge-hallyn)]

I also verified on maverick. Note that the directions in the description are not right. Comment #39 gives the right recipe. In any case, -proposed fixes it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 83-0ubuntu3.1maverick

---------------
ecryptfs-utils (83-0ubuntu3.1maverick) maverick-proposed; urgency=low

  * Cherry pick upstream bzr commit r520
  * src/utils/mount.ecryptfs_private.c:
    - fix bug LP: #313812, clear used keys on unmount
    - add ecryptfs_unlink_sigs to the mount opts, so that unmounts from
      umount.ecryptfs behave similarly
    - use ecryptfs_remove_auth_tok_from_keyring() on the sig and sig_fnek
 -- Dustin Kirkland <email address hidden> Fri, 11 Feb 2011 17:21:59 -0600

[Dustin Kirkland  (kirkland)]

User over in Bug #725862 is reporting a regression in Maverick after taking this update....

[Thiago Martins (martinx)]

I'm seeing this problem with Ubuntu 14.10 when using `init=/lib/systemd/systemd` but I'm not sure if it is related or not... :-/

[papukaija (papukaija)]

@Thiago: Please open a new bug if you still experience issues with ecryptfs, as this bug has is fixed. Thanks.