Cannot open Private directory after a reboot when "Automatic Login" enabled

When you run ecryptfs-setup-private, are you *absolutely* sure that
the first passphrase you gave, when it asked for your "login"
passphrase, was in fact, the password you use to log into the system?

:-Dustin

Yes, I did use my login password, I've used the force option three times using the same login password and I still get the same error on reboot.

I created a new user and set up the private directory and it worked as the way it should, so I went into my home directory and deleted .Private and .ecryptfs and set up a private directory and it now works correctly.

I now have run into another problem. Before leaving my home directory I umounted the private directory, then logged in as my other user, the private directory was not mounted, so I mounted it using one of the scripts I created to mount and umount the private directory. I then switched users to my main user and the private directory was mounted and accessible. So when a user mounts the private directory in their home directory, all private directories get mounted system wide.

Mount script:
#!/bin/sh
mount.ecryptfs_private

Umount script:
#!/bin/sh
umount.ecryptfs_private

Hello, thanks for reporting bugs to Ubuntu.

Please forgive me, I'm a little baffled on this bug report...

First, please correct the title/description, as I don't think:
 "Can open Private directory after a reboot"
is what you mean as the topic of this bug.

Second, if that bug is solved, let's mark it as such. Please open a
new bug for new issue.

Third, I can't see any way that it's possible for
mount.ecryptfs_private or umount.ecryptfs_private to operate on a
system-wide basis. In the new bug that you open on that issue, I'm
going to need detailed instructions on how to reproduce this behavior.

:-Dustin

Change that to Can't open Private directory after reboot.

I must of had my stupid hat on yesterday, as I can't duplicate the problem I was having with being able to open private directories system wide.

Please mark this bug solved

Jim

Thanks!!!

The bug "Can't open Private Directory after reboot" affects me as well.

I am positive that I have the same passphrase as my login password, and get the same error message
 "keyctl_search: Required key not available"

Rune

Please attempt to run:
 $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase [LOGIN_PASSPHRASE]

And see if that utility is able to unwrap your mount passphrase.

:-Dustin

Same problem here, even after deleting .ecryptfs .Private and Private folders.
After reboot, Private is not automounted.
Doubleclicking on that long softlink found in Private doesnt do anything.
Executing mount.ecryptfs_private in terminal returns: required key not found.
Executing "ecryptfs-mount-private" in terminal does the job, finally.

Dustin,

ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase [LOGIN_PASSPHRASE] (with my actual login password) returns
Unable to read salt value from user's .ecryptfsrc file; using default fa0ec2d..........

Clicking the link in ~/Private after this does not mount the directory, and the commands "mount.ecryptfs_private" and "ecryptfs-mount-private" still gives the error message "keyctl_search: Required key not available".

ls -la ~/.ecryptfs shows:
drwx------ 2 rune rune 4096 2008-10-14 14:26 .
drwxr-xr-x 70 rune rune 4096 2008-10-20 08:51 ..
-rw-r--r-- 1 rune rune 0 2008-10-14 14:26 auto-mount
-rw-r--r-- 1 rune rune 0 2008-10-14 14:26 auto-umount
-rw-r--r-- 1 rune rune 17 2008-10-14 14:26 Private.sig
-r-------- 1 rune rune 48 2008-10-14 14:26 wrapped-passphrase

Rune

Did you run ecryptfs-setup-private from the command line, or did you choose to have an encrypted private directory in the installer?

When you run 'ecryptfs-unwrap-passphrase', after the warning about the salt value, does it return your mount passphrase? What's the exit code? (Hint: echo $?)

Make sure you quote your login passphrase if you have any funny characters.

:-Dustin

I have been running Intrepid since alpha3, and installed it using the command line instructions in the release notes. I did however already have ecryptfs as I already used it in a more manual way. (adding the passphrase=login password using ecyprfs-manager).

When running 'ecryptfs-unwrap-passphrase' I the message
 "Unable to read salt value from user's .ecryptfsrc file; using default fa0ec2dfef0ab60d305d97d36a5c...."
and the fa0... part is the actual response, which is not my password.

'echo $?' gives "0"

I have no funny characters in my login phrase and quoting it does not make a difference to the output.

Regards,

Rune

Rune-

That "fa....5c" value is your *mount* passphrase, which you have just published to the internet. Consider any data there compromised.

Guys-

There are 2 passphrases involved.
  1) There's your login_passphrase (what you use to login to the system)
  2) And there's your mount_passphrase (what is used to mount the ~/Private directory and encrypt/decrypt the data there)

When you successfully login to your system, a PAM module in the authentication stack called pam_ecryptfs takes your login_passphrase, and uses that to decrypt a file, ~/.ecryptfs/wrapped-passphrase, which contains your mount_passphrase.

If that file is successfully decrypted, your decrypted mount_passphrase will be inserted into your kernel keyring.

Then, pam_ecryptfs will attempt to run /sbin/mount.ecryptfs_private, which will try to mount your ~/Private directory using the passphrase which was added to the keyring. If the mount_passphrase not able to be retrieved and added to the kernel keyring, you will get the "keyctl_search: Required key not available" error.

This is what should happen automatically.

To find out where the problem is, you can perform each of these steps manually.

First, you need to figure out if you can decrypt your mount_passphrase, using 'ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE'. You will probably get the salt warning, and then if it succeeds, it will print the mount_passphrase to the screen. When you ran ecryptfs-setup-private, you were able to either choose your own mount_passphrase or have one generated for you. If you had one generated for you, it would be 128-bits of random data, represented by a string of hexadecimal digits. In any case, if ecryptfs-unwrap-passphrase is able to print it to screen, that's good. Check the exit code (echo $?) immediately after running ecryptfs-unwrap-passphrase, and ensure that it's 0. Otherwise, your wrapped-passphrase file is probably encrypted using a different password than the one you supplied.

Once you're able to successfully decrypt ~/.ecryptfs/wrapped-passphrase (and please don't post your passphrases here), run 'ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE'. This will add the passphrase to the kernel keyring. You can list the id's of the keys in the keyring using: 'keyctl show'. Note that you might need to install the 'keyutils' package.

Now that you have the passphrase in the keyring, you should be able to mount your encrypted private directory with 'mount.ecryptfs_private'.

If you're still getting "keyctl_search: Required key not available", then the wrong passphrase has been inserted into your keyring. You can check what key mount.ecryptfs_private expects with 'cat ~/.ecryptfs/Private.sig'. This "signature" should match the signature of the key in your keyring, as shown by 'keyctl show'.

I would very much appreciate it if the people on this bug experiencing this problem could walk through these steps and please tell me where you are experiencing the failure.

:-Dustin

I seem to have the same problem. Here's what I did:
1. I ran ecryptfs-setup-private
2. I put in the wrong password, but it succeeded anyway
3. I tried to rerun ecryptfs-setup-private with the --force switch, it wouldn't work
4. There was a PAM update that I saw go through yesterday? Not sure if it's related
5. The --force started to work and I can get it to work, but once I reboot, I lose access and get "keyctl_search: Required key not available"
6. 'ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE' returns "Unable to read salt value from user's .ecryptfsrc file; using default"
7. I typed in my own passphrase during setup, Private.sig and 'keyctl show' do return the same value.

Thank you for your response, I will test this shortly.

Please not that the output I posted is not the complete output of the unwrap
command.

In any case, is it possible to take the mount_passphrase and reverse it in
order to compare it to the original login_passphrase ? Or can one
mount_passphrase be generated from different login passwords ?

Rune

2008/10/21 Dustin Kirkland <email address hidden>

> Rune-
>
> That "fa....5c" value is your *mount* passphrase, which you have just
> published to the internet. Consider any data there compromised.
>
> Guys-
>
> There are 2 passphrases involved.
> 1) There's your login_passphrase (what you use to login to the system)
> 2) And there's your mount_passphrase (what is used to mount the ~/Private
> directory and encrypt/decrypt the data there)
>
> When you successfully login to your system, a PAM module in the
> authentication stack called pam_ecryptfs takes your login_passphrase,
> and uses that to decrypt a file, ~/.ecryptfs/wrapped-passphrase, which
> contains your mount_passphrase.
>
> If that file is successfully decrypted, your decrypted mount_passphrase
> will be inserted into your kernel keyring.
>
> Then, pam_ecryptfs will attempt to run /sbin/mount.ecryptfs_private,
> which will try to mount your ~/Private directory using the passphrase
> which was added to the keyring. If the mount_passphrase not able to be
> retrieved and added to the kernel keyring, you will get the
> "keyctl_search: Required key not available" error.
>
> This is what should happen automatically.
>
> To find out where the problem is, you can perform each of these steps
> manually.
>
> First, you need to figure out if you can decrypt your mount_passphrase,
> using 'ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
> LOGIN_PASSPHRASE'. You will probably get the salt warning, and then if
> it succeeds, it will print the mount_passphrase to the screen. When you
> ran ecryptfs-setup-private, you were able to either choose your own
> mount_passphrase or have one generated for you. If you had one
> generated for you, it would be 128-bits of random data, represented by a
> string of hexadecimal digits. In any case, if ecryptfs-unwrap-
> passphrase is able to print it to screen, that's good. Check the exit
> code (echo $?) immediately after running ecryptfs-unwrap-passphrase, and
> ensure that it's 0. Otherwise, your wrapped-passphrase file is probably
> encrypted using a different password than the one you supplied.
>
> Once you're able to successfully decrypt ~/.ecryptfs/wrapped-passphrase
> (and please don't post your passphrases here), run
> 'ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-
> passphrase LOGIN_PASSPHRASE'. This will add the passphrase to the
> kernel keyring. You can list the id's of the keys in the keyring using:
> 'keyctl show'. Note that you might need to install the 'keyutils'
> package.
>
> Now that you have the passphrase in the keyring, you should be able to
> mount your encrypted private directory with 'mount.ecryptfs_private'.
>
> If you're still getting "keyctl_search: Required key not available",
> then the wrong passphrase has been inserted into your...

> 2. I put in the wrong password, but it succeeded anyway

You entered the "wrong" login passphrase twice?

:-Dustin

On Tue, Oct 21, 2008 at 10:53 AM, Rune Evjen <email address hidden> wrote:
> In any case, is it possible to take the mount_passphrase and reverse it in
> order to compare it to the original login_passphrase ? Or can one
> mount_passphrase be generated from different login passwords ?

The mount_passphrase is generated from /dev/urandom, and encrypted
with the login_passphrase that you enter (twice) in
ecryptfs-setup-private.

If you can decrypt it using ecryptfs-unwrap-passphrase with your
current login passphrase, then it's wrapped correctly. If you can
insert into your keyring, then the kernel knows about it. And if the
signature in Private.sig and keyctl match, then it's the "correct"
key. The mount should definitely succeed.

I want to revisit something Matt wrote, about entering the wrong login
password (twice). ecryptfs-setup-private is not able to validate your
login password. It expects that you know your password, and that
you're going to enter it correctly, and twice. It uses that value to
encrypt the mount passphrase, even if it's not your actual login
passphrase. That could easily be the source of these troubles...

:-Dustin

Yes, I didn't realize that it was asking for my login password; temporary brain cramp. I can type my password twice though... :)

So, I put in a different password, thinking it was for mounting the encrypted folder. Then I put it in a 2nd time to confirm. Then it asked for another password, I put in the same one, at this point, I realized that I was doing something wrong, but I can't go back, so I put it in a 4th time.

So, I wanted to recreate it properly with the --force command. That didn't work at first, but now it does. Except for the reboot part. When I recreate it now, with the --force command, just in case, I put in my login password twice, then a different passphrase of my choosing. Every reboot, I get the error above.

Test Result

1. First, you need to figure out if you can decrypt your mount_passphrase, using 'ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE'.

Result: Received salt warning, command printed the hex digits and returned 0

2. Once you're able to successfully decrypt ~/.ecryptfs/wrapped-passphrase, run ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE'.

Result: Received salt warning, and "Inserted auth tok with sig [xxxxxx...x] into the user session keyring

3. You can list the id's of the keys in the keyring using: 'keyctl show'.

Result: keyctl shows two user keys, one match to the result of the command 'ecryptfs_insert_wrapped_passphrase_into_keyring..' and another key. (Note: I already had used ecryptfs earlier in a more manual way for other directories, is the other key my old key and is this creating the problem with automount after reboot ?)

4. Now that you have the passphrase in the keyring, you should be able to mount your encrypted private directory with 'mount.ecryptfs_private'.

Result: Using the 'mount.ecryptfs_private' command I can succsessfully mount (and decrypt the contents of) my ~/Private directory.

5. Reboot persistency
After applying the above commands and accessing ~/Private, I rebooted and ran 'mount.ecryptfs_private' which again gave the error "keyctl_search: Required key not available"
'keyctl show' does not list my key, only my "old" key (see 3).

After adding it with 'ecryptfs-insert-wrapped-passphrase-into-keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD' and running 'mount.ecryptfs_private' again the ~/Private directory is mounted ok.

6. Summary
So it seems like the problem for me is that my "wrapped passphrase" is not automatically added into the keyring.
Is this because I have two keys ? (See note in 3)
In another computer I use this is working fine, but on that computer I didn't use ecryptfs prior to using the Ubuntu "Private directory" feature.

Regards,

Rune

Rune-

Cool, thanks for the details. Multiple keys in the keyring should be fine. The file ~/.ecryptfs/Private.sig tells mount.ecryptfs_private which key should be used.

It sounds like your PAM configuration isn't correct.

Could you please post /etc/pam.d/common-session, /etc/pam.d/common-auth, and /etc/pam.d/common-password?

Also, could you indulge me with your ecryptfs and pam versions?
 $ dpkg -l | grep ecryptfs
 $ dpkg -l | grep pam

:-Dustin

It works for me now. Not sure what came through with the last set of updates today. I saw kernel and video driver updates, plus a bunch of others. I wasn't looking to hard to see if there was anything with PAM.

I take that back. It seemed to work upon a couple previous reboots. Now when I reboot, I try to mount it and I get the old message back:
keyctl_search: Required key not available

Last time I rebooted, I waited a minute and then tried again and it mounted. Weird... This time I had to wait about 5 minutes. I tried once a minute, give or take, it kept failing, but then it worked.

Dustin,

Attached are the pam.d files.

'dpkg -l | grep ecryptfs':
ii ecryptfs-utils 53-1ubuntu10 ecryptfs cryptographic filesystem (utilities
ii libecryptfs0 53-1ubuntu10 ecryptfs cryptographic filesystem (library)

' dpkg -l | grep pam'
ii bogofilter 1.1.7-1ubuntu1 a fast Bayesian spam filter (dummy package)
ii bogofilter-bdb 1.1.7-1ubuntu1 a fast Bayesian spam filter (Berkeley DB)
ii bogofilter-common 1.1.7-1ubuntu1 a fast Bayesian spam filter (common files)
ii libpam-ck-connector 0.2.10-1ubuntu8 ConsoleKit PAM module
ii libpam-gnome-keyring 2.24.1-0ubuntu1 PAM module to unlock the GNOME keyring upon
ii libpam-modules 1.0.1-4ubuntu5 Pluggable Authentication Modules for PAM
ii libpam-runtime 1.0.1-4ubuntu5 Runtime support for the PAM library
ii libpam0g 1.0.1-4ubuntu5 Pluggable Authentication Modules library
ii python-pam 0.4.2-12ubuntu2 A Python interface to the PAM library

Hi Rune,

You appear not to be using the system-managed /etc/pam.d/common-* files provided by pam-auth-update in Ubuntu 8.10. Is this intentional?

If you run 'sudo pam-auth-update --force', you can turn these files over to the system for automatic management. I don't see anything unusual in your config, so this should be safe to do. Once you've done this, pam_ecryptfs should be automatically added to common-session for you.

Rob H-

Can you check as well?

 $ grep pam_ecryptfs /etc/pam.d/*

:-Dustin

Steve,

I ran 'sudo pam-auth-update --force' and checked both "eCryptfs Key/Mount Management" and "ConsoleKit Session Management" which were unchecked.

After rebooting my laptop the ~/Private directory automounted.

It was not intentional to keep an old pam.d configuration.

I was already using ecyptfs before installing the Ubuntu Private directory feature, so maybe this is the reason why my pam.d setup was different, although I cannot recollect wheter I was given the option to keep the pam.d confirguration or install the package maintainer version during upgrade.

Anyway, thank you Steve and Dustin for solving this!

Regards,

Rune

I'll try to add something to Launchpad Questions/Answers for ecryptfs, since it seems a few users have experienced and solved this entirely as a configuration problem.

Thanks,
:-Dustin

Dustin, here's the output of the grep command:
/etc/pam.d/common-auth:auth optional pam_ecryptfs.so unwrap
/etc/pam.d/common-password:password optional pam_ecryptfs.so
/etc/pam.d/common-session:session optional pam_ecryptfs.so unwrap

I'm still at the point where it will work after a reboot, but not immediately, I have to wait at least 5 minutes now before it will mount. I don't need it to automount though...

Steve-

Any ideas about an arbitrary delay of roughly 5 minutes that PAM might
somehow introduce?

Rune-

Do you have any cronjobs running?

:-Dustin

Now it's been a few hours since my last reboot (patches this AM) and it won't mount at all.

Odd, now it mounted. I rebooted around 9:30 AM, it's not 1:22 PM and it mounts.

But it's RO. I can't write to it...

drwx------ 2 rth rth 4096 2008-10-21 11:04 Private
drwx------ 2 rth rth 4096 2008-10-21 11:04 .Private

That should mean that I can write to it.

Rob-

Do you have any cronjobs running as your normal user, or as root?

 $ crontab -l
 $ sudo crontab -l
 $ ls -alF /etc/cron*

:-Dustin

No.

rth@u64:~$ crontab -l
no crontab for rth
rth@u64:~$ sudo crontab -l
[sudo] password for rth:
no crontab for root
rth@u64:~$ ls -alF /etc/cron*
-rw-r--r-- 1 root root 724 2008-04-08 14:13 /etc/crontab

/etc/cron.d:
total 32
drwxr-xr-x 2 root root 4096 2008-10-18 22:58 ./
drwxr-xr-x 141 root root 12288 2008-10-25 09:30 ../
-rw-r--r-- 1 root root 244 2007-03-05 09:32 anacron
-rw-r--r-- 1 root root 499 2008-10-14 16:23 php5
-rw-r--r-- 1 root root 102 2008-04-08 14:13 .placeholder
-rw-r--r-- 1 root root 1323 2008-03-31 09:16 postgresql-common

/etc/cron.daily:
total 76
drwxr-xr-x 2 root root 4096 2008-10-24 06:51 ./
drwxr-xr-x 141 root root 12288 2008-10-25 09:30 ../
-rwxr-xr-x 1 root root 311 2007-03-05 09:32 0anacron*
-rwxr-xr-x 1 root root 633 2008-06-25 10:01 apache2*
-rwxr-xr-x 1 root root 219 2008-05-20 02:54 apport*
-rwxr-xr-x 1 root root 7680 2008-08-14 12:56 apt*
-rwxr-xr-x 1 root root 314 2008-04-04 05:53 aptitude*
-rwxr-xr-x 1 root root 502 2007-12-12 10:31 bsdmainutils*
-rwxr-xr-x 1 root root 89 2006-06-19 15:14 logrotate*
-rwxr-xr-x 1 root root 954 2008-03-12 09:28 man-db*
-rwxr-xr-x 1 root root 646 2008-06-26 10:19 mlocate*
-rwxr-xr-x 1 root root 1154 2008-03-07 15:37 ntp*
-rw-r--r-- 1 root root 102 2008-04-08 14:13 .placeholder
-rwxr-xr-x 1 root root 383 2008-07-25 02:40 samba*
-rwxr-xr-x 1 root root 3349 2008-09-09 15:52 standard*
-rwxr-xr-x 1 root root 1309 2007-11-23 04:02 sysklogd*

/etc/cron.hourly:
total 20
drwxr-xr-x 2 root root 4096 2008-10-18 22:28 ./
drwxr-xr-x 141 root root 12288 2008-10-25 09:30 ../
-rw-r--r-- 1 root root 102 2008-04-08 14:13 .placeholder

/etc/cron.monthly:
total 28
drwxr-xr-x 2 root root 4096 2008-10-18 22:58 ./
drwxr-xr-x 141 root root 12288 2008-10-25 09:30 ../
-rwxr-xr-x 1 root root 313 2007-03-05 09:32 0anacron*
-rw-r--r-- 1 root root 102 2008-04-08 14:13 .placeholder
-rwxr-xr-x 1 root root 129 2008-04-08 14:13 standard*

/etc/cron.weekly:
total 40
drwxr-xr-x 2 root root 4096 2008-10-20 19:26 ./
drwxr-xr-x 141 root root 12288 2008-10-25 09:30 ../
-rwxr-xr-x 1 root root 312 2007-03-05 09:32 0anacron*
-rwxr-xr-x 1 root root 99 2008-08-20 05:55 apt-xapian-index*
-rwxr-xr-x 1 root root 528 2008-03-12 09:28 man-db*
-rw-r--r-- 1 root root 102 2008-04-08 14:13 .placeholder
-rwxr-xr-x 1 root root 2016 2008-05-06 12:46 popularity-contest*
-rwxr-xr-x 1 root root 1220 2007-11-23 04:02 sysklogd*

No idea why you would have a five-minute delay; anything loaded from pam's session modules should happen synchronously within gdm before login, TTBOMK.

cron was my first guess as well, but the evidence doesn't seem to point that way?

10 minutes into a reboot, same deal, can't mount it.

Well, it still won't mound, I still get:
$ mount.ecryptfs_private
keyctl_search: Required key not available

Rob-

Reboot.

Login.

Run: "keyctl show". This should show the signature of the key used
(not the key itself. Does that signature matches the value in
~/.ecryptfs/Private.sig?

If that key signature is missing, or two two do not match, that's
where we need to start debugging this problem.

:-Dustin

$ keyctl show
Session Keyring
       -3 --alswrv 1000 -1 keyring: _uid_ses.1000
404603209 --alswrv 1000 -1 \_ keyring: _uid.1000
$ cat ~/.ecryptfs/Private.sig
[removed]

Not the same... I recall doing this before and they did match (see earlier in this thread).

Rob,

Might your problem be related to Bug #290445, having any strange
characters in your passphrase? Please don't reveal your passphrase,
but there is a known bug (with a fix coming)...

:-Dustin

My passphrase has an "!" in it...

Okay, it's my best guess at this point that you're suffering from some
weird perturbation of Bug #290445.

The fix for that bug should land in intrepid-updates within a day or two.

If you'd like to try it now, though, you can try
ecryptfs-utils_53-1ubuntu12~ppa1 in my PPA:
 * https://edge.launchpad.net/~kirkland/+archive

You will need to upgrade to this newer version of ecryptfs-utils, and
then you'll need to re-run "ecryptfs-setup-private --force". To do
that, you might need to move any data you currently have out of
~/Private.

:-Dustin

At some point over the last couple of hours, it worked. When I got up this morning, it wasn't mounted. When I logged in from work, it was mounted and the keyctl show and cat show the same thing now. So, I'm thinking that that bug is not affecting me?

I think it's fixed. I had X automatically log me in because I was having X issues a few weeks ago. So, remote reboots, no login, etc, etc. Anyway, it seems that once I put in the password, it's all good.

Based on above bug descriptions, I figured it might have to do with the new "automatic login" feature in 8.10. So I clean installed 8.10 final, enabled "automatic login" through the graphical installer, and followed the steps required to get the Private directory working. To little surprise, I can confirm the behaviour:

$ mount.ecryptfs_private
keyctl_search: Required key not available

I tried rebooting, logging out (interestingly enough, logging out with automatic login logs the user right back in automagically), and many other voodoo-like things, but I could not get it to work, whether I removed the folders or used --force.

After disabling automatic login and redoing the steps, it immediately worked as expected. It auto-mounts now.

I hope that helps.

ubuntostones-

Aha! Thanks for the excellent detective work.

Absolutely, automatic mounting of encrypted ~/Private cannot work with
automatic logins.

Mounting of encrypted ~/Private requires you to enter your password at
login. If you have not done so, the required key is not present, and
thus it will not be mountable.

As I'm a Server Developer (no gui, no automatic logins there), I'll
need to have a discussion with the Desktop guys to collaborate on a
way to solve this.

Thanks,
:-Dustin

Okay, I have confirmed this bug, when a system is set to "automatically login". I'm going to update the title of the bug accordingly.

:-Dustin

I'm attaching a debdiff that fixes this for Intrepid, and request that this be sponsored for intrepid-proposed. I'll do the SRU momentarily.

:-Dustin

Fix committed to upstream git repository:
 * http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=923a2e4bc05e8a6bb4a3ca836f9080b13bd84b3c

Will be released in version 64.

:-Dustin

Dustin,

thanks a lot for working on this. I read the upstream commit, and it is a great improvement to the current situation. Using a Terminal is okay for now, since there are no cross-distro tools for DE agnostic password input. Using gksu if it exists would be a nice improvement, of course. I really like the idea of using a .desktop file, that should behave very well in file managers.

As for your debdiff:

  * Please don't use /usr/share/app-install/ for the .desktop file. That's used by gnome-app-install, and announcing this as an application doesn't make sense. For the same reason it shouldn't be under /usr/share/applications. I suggest to simply use /usr/share/ecryptfs-utils/.

 * Minor gotcha: You install ecryptfs-mount-private.txt into /usr/share/doc/ecryptfs-utils/. Debian Policy (12.3) requires that you are able to rm -r /usr/share/doc without any program behaviour. Also, it is not really helpful documentation in the sense of "I read this before installation". Thus I suggest to put it into /usr/share/ecryptfs-utils/, too.

 * debian/ecryptfs-utils.install: Oh, I wasn't aware that it's possible nowadays to specify absolute paths. If that works, I learned something new today. :-)

Many thanks for working on this!

Updated patch attached, per Martin's comments.

Upstream commit:
 * http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=168fab4991929b89220d006fe4b2df007871ba8a

:-Dustin

Stable Release Update Request

Per:
 * https://wiki.ubuntu.com/StableReleaseUpdates

 1) This bug affects any users using Intrepid's easy-to-configure "Automatic Login" option, in conjunction with Encrypted Private Directories. Encrypted Private Directories absolutely *require* that you enter your password at some point, in order to unwrap the mount passphrase and mount the encrypted Private directory. This might seem obvious to the technical among us, but it's not obvious to some of our users.

 2) The proposed fix, which has been committed upstream, involves the following, in order to provide an interactive mechanism for prompting for a password when attempting to access the encrypted private directory:
  * doc/ecryptfs-mount-private.txt: new file, to be placed as
    "README.txt" in a user's unmount encrypted ~/Private directory
  * src/desktop/ecryptfs-mount-private.desktop: new desktop file,
    to be installed in each user's unmounted Private dir, providing a
    clickable way to mount (tested in Gnome and KDE)
  * src/utils/ecryptfs-setup-private: link the readme and desktop file
    into the unmount Private dir
  * src/utils/ecryptfs-mount-private: completely overhauled to
    interactively prompt for a user's login password, unwrap the mount
    passphrase and insert into the keyring, and perform the mount
  * src/utils/ecryptfs-umount-private: completely overhauled to drop the
    deprecated (and broken) counter mechanism, and very simply call
    umount.ecryptfs_private
  * src/utils/mount.ecryptfs_private.c: provide a helpful "hint" when a
    key isn't found, that perhaps they user wants to try the interactive
    ecryptfs-mount-private utility
  * See: http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=923a2e4bc05e8a6bb4a3ca836f9080b13bd84b3c

 3) Patch is attached.

 4) TEST CASE:
  a) install Ubuntu or Kubuntu, and configure the system for "Automatic Login"
  b) sudo apt-get install ecryptfs-utils
  c) ecryptfs-setup-private
  d) mount.ecryptfs_private
  e) copy some data into ~/Private
  f) reboot, allow the machine to automatically login
  g) try to access ~/Private, only will see symlink saying that the directory has been unmounted

 5) The only regression potential I see is the overloading of the ecryptfs-mount-private and ecryptfs-umount-private utilities. These were two small, wrapper scripts which have been included in the package, but broken and deprecated. Their functionality was completely supplanted by the mount.ecryptfs_private setuid binary and the built-in counter functionality, and the hooks in pam_ecryptfs to call mount.ecryptfs_private/umount.ecryptfs_private. Before the pam module handled this, these utilities were added to .bash_profile. That never made it into Ubuntu, and these utilities have not been used. As upstream, the intention is for these utilities to become the interactive wrapper for the compact, hardened /sbin/mount.ecryptfs_private.

:-Dustin

Patch updated to remove 3 lines of non-functional shell code in the new ecryptfs-mount-private script.

:-Dustin

Thanks! I fixed the upload target to "intrepid-proposed" and uploaded. I'll accept it once the previous SRU (bug #290445) is verified and moves to -updates.

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Judging by the comments in #48 above, I suspect my problem is related.

I can log in to my test machine at the keyboard, and the ~/Private directory is properly mounted. SSH in using public keys (authorized_keys), and it is not mounted.

ccurley@grissom:~$ /sbin/mount.ecryptfs_private
keyctl_search: Required key not available
ccurley@grissom:~$ keyctl show
Session Keyring
       -3 --alswrv 1000 -1 keyring: _uid_ses.1000
202034337 --alswrv 1000 -1 \_ keyring: _uid.1000
ccurley@grissom:~$

I believe that indicates that the keyring is empty.

I ran through Mr. Kirkland's exercise in comment 13 above, and was able to mount the directory correctly.

ccurley@grissom:~$ ll Private/
total 20
drwx------ 2 ccurley ccurley 4096 2008-11-06 18:57 .
drwxr-xr-x 36 ccurley ccurley 4096 2008-11-06 20:31 ..
-rw-r--r-- 1 ccurley ccurley 15 2008-11-06 18:57 test
ccurley@grissom:~$

I hope the proposed fix handles the case of SSH as well.

This -proposed fix worked for me. Be advised that I did not test SSH though. Regards...

I activated auto-login, rebooted, and as expected ended up with ~/Private being unmounted. It had one file in it:

  lrwxrwxrwx 1 martin martin 28 2008-10-28 16:54 THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA -- Run mount.ecryptfs_private to mount again -> /sbin/mount.ecryptfs_private

There was no "readme.txt" file as I would have expected from the debdiff. Also, running this script (or mount.ecryptfs_private directly) did not work, I wasn't prompted for my password and the process just exited with status 1. The only way to recover was to open a terminal and do "su - martin".

So this doesn't work for me.

Martin-

The fix, as proposed, will only solve this comprehensively for *newly*
created encrypted-private setups, with the patched
ecryptfs-setup-private.

I didn't think it appropriate for upgrading the package to go digging
in user's unmounted ~/Private directory, creating symlinks to the
readme.txt and .desktop file.

If this is really, really what we want, we could hook
ecryptfs-mount-private with a *hack*, that would check for the
existence of these links in an unmounted Private dir, and create them
just before mounting.

Is that what you'd want?

:-Dustin

One update to my last post... That hack might actually have to go
into pam_ecryptfs.so.

:-Dustin

Oh, thanks for the explanation, I wasn't aware that those files were there only for newly encrypted ones. No, let's not touch user's ~ on upgrade, that's fine.

Documented manually adding the symlinks to a legacy-installed
encrypted private directory here:

https://help.ubuntu.com/community/EncryptedPrivateDirectory

:-Dustin

The fix doesn't seem to work for me, i.e. I can't mount when I login from SSH using public key auth. Also, I followed the instructions posted above to create the symlinks in my unmounted Private directory, but the files those symlinks should point to aren't there on my system.

For reference:

tawmas@tylke:~/Private$ apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: 53-1ubuntu12
  Candidate: 53-1ubuntu12
  Version table:
 *** 53-1ubuntu12 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

tawmas@tylke:~/Private$ ls -l /usr/share/ecryptfs-utils/
ls: cannot access /usr/share/ecryptfs-utils/: No such file or directory

(I just upgraded to Jaunty, but had already tested SSH access on Intrepid, with intrepid-proposed enabled and all upgrades applied).

This bug was fixed in the package ecryptfs-utils - 66-2ubuntu1

---------------
ecryptfs-utils (66-2ubuntu1) jaunty; urgency=low

  * Merge from debian unstable,
    (LP: #259631, #293433, #286265, #247421, #294888, #298421)
  * Remaining changes:
    - debian/ecryptfs-utils.postinst: handle pam-auth-update (Bug: #506172)
    - debian/rules:
      + keep the dpatch infrastructure around, as we'll likely
        need it again at some point soon
      + install the desktop, readme, and pam-auth-update files ()
    - debian/ecryptfs-utils.install: install the desktop, readme shared files
      (Bug: #506172)
    - debian/control:
      + keep the dpatch build dep
      + depend on libpam-runtime (Bug: #506172)
    - debian/ecryptfs-utils.prerm: remove pam-auth-update configuration
      (Bug: #506172)
    - debian/ecryptfs-mount-private.txt: readme to install in unmounted
      private dir (Bug: #506172)
    - debian/ecryptfs-mount-private.desktop: desktop link to install in
      unmounted private dir (Bug: #506172)
    - debian/ecryptfs-utils.dirs: usr share install dirs (Bug: #506172)
    - debian/ecryptfs-utils.pam-auth-update: pam stack configuration
      (Bug: #506172)

ecryptfs-utils (66-2) unstable; urgency=low

  * Removing auth-client-config support, no longer used.
  * Adding ecryptfs-utils recommends to keyutils.
  * Building without ssl, ecryptfs_key_mod_openssl.c has incompatible
    license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_pkcs11_helper.c
    links against openssl and has incompatible license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_tspi.c links
    against openssl and has incompatible license (GPL-2+).

ecryptfs-utils (66-1) unstable; urgency=low

  * Manually adding second line of the commit message when merging
    upstream version 65 to changelog.
  * Merging upstream version 66.
  * Adding ecryptfs-utils.postinst to create /var/lib/ecryptfs on
    package installation time.

ecryptfs-utils (65-1) unstable; urgency=low

  * Merging upstream version 65:
    - Adds --wrapping option to ecryptfs-setup-private command to use an
      independent wrapping passphrase, different from the login passphrase
      (Closes: #505008).
  * Removing pam-doc.dpatch, went upstream.
  * Adding build-depends to swig.
  * Adding build-depends to python-dev.
  * Including python bindings in libecryptfs0.

ecryptfs-utils (64-3) unstable; urgency=low

  * Replacing obsolete dh_clean -k with dh_prep.
  * Adding patch from Osamu Aoki <email address hidden> to update
    ecryptfs-pam-doc.txt contents with s/Confidential/Private/
    (Closes: #504934).
  * Updating homepage and download location in control and copyright
    (Closes: #504930).
  * Updating author information in copyright.
  * Installing desktop shortcut and readme to /usr/share/ecryptfs-utils.
    Together with the fixes of upstream version 64, this interactively prompts
    for passwords now (Closes: #504370).

ecryptfs-utils (64-2) unstable; urgency=low

  * Adding build-depends to python (Closes: #504719).

ecryptfs-utils (64-1) unstable; urgency=low

  * Removing sbin-path.dpatch, not needed anymore.
  * Building with --enable-static, ...

I have the same problem.

My install was an 8.04 and I did an upgrade to 8.10. I had it set up under 8.04 to automatically log me in.

I had some success but it isn't persistent. Also the following command:

ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE

doesn't work for me. I have to replace the underscores in the command to be hypens, so the following command works:

ecryptfs-insert-wrapped-passphrase-into-keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE

I had to install keyutils

I set my system to not automatically login. This didn't make a difference. I have to issue the command:

ecryptfs-insert-wrapped-passphrase-into-keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSPHRASE

after each log in, regardless of whether I'm set up to automatically log in or not.

then I can mount the private encrypted directory with the following command:

mount.ecryptfs_private

Now, really I do find it a big contradiction to allow someone to sit down at my workstation while I'm not there and get into the private directory. What's the purpose if not to ensure that certain files are not accessible to anyone but me. It would seem the way to really make this work is to allow me to double click on it say in nautilus and be prompted for my pass key, or to mount it and be prompted (the same way sudo does).

I can't afford the focus nor the time to log out each time I walk away from the computer and if you say that lock the screen after x amount of time, that sort of minimizes (and somewhat negates) the need to encrypt things.

Issuing the two commands at the prompt sort of secures things for me but it is very inconvenient and the fact that the command is quite lengthy. I also issue a lot of commands at the terminal prompt so I'd have to scroll back a lot over time. I'd find myself using it less and less till it falls to obscurity, thus making this "alleged" innovative and compelling feature pointless.

Jim, please note that the fix in this bug, to get a "clickable"
unencryption, only applies to newly created private directories.

Also, this feature isn't really pointless IMHO, it works very well for
people without autlogin. With this fix it works reasonably well for
autologins as well, it's just quite impossible to transition an
already existing private directory to this fix.

I still an unable to mount the private directory. When I run 'ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase PASSPHRASE' it tells me the command is not found, changing it to 'ecryptfs-insert-wrapped-passphrase-into-keyring ~/.ecryptfs/wrapped-passphrase PASSPHRASE' gives me Unable to read salt value from user's .ecryptfsrc file; using default
Error attempting to unwrap passphrase and insert into the user session keyring; rc = [1]. Check the system log for more information from libecryptfs.

The log tells me under messages that 'Nov 24 08:55:06 alan ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to parse .ecryptfsrc file; rc = [-5]' and 'Nov 24 08:55:07 alan ecryptfs-insert-wrapped-passphrase-into-keyring: Passphrase key already in keyring'

I guess everything is working fine but somehow I am still unable to mount it. Help is much appreciated.

Jim-

I have posted instructions at:
 * https://help.ubuntu.com/community/EncryptedPrivateDirectory

As to how to add links to your unmounted Private directory, that would
allow you to double click on "Access Your Private Data" link, enter
your password, and then mount your private directory.

:-Dustin

am28111-

 * The "salt value" messages are merely warnings, and are benign, and
will not cause a problem.
 * The "ecryptfs_insert_wrapped_passphrase_into_keyring" bit was a
typo on my part. Replace the underscores with hyphens.
 * If you're getting "Error attempting to unwrap passphrase", then you
probably have a passphrase wrong.

:-Dustin

Dustin-

Thanks for the reply. Unfortunately, I could not figure out what the login passphrase was so I just uninstalled the whole thing using the instructions at:
https://help.ubuntu.com/community/EncryptedPrivateDirectory

I then reinstalled it, but for some reason, I still can't get the Private Directory icon to show up on the desktop like it used too. I will try searching around for the answer.

People complained about the Private directory showing up on the
desktop and it was removed in a separate patch to Gnome somewhere (not
in ecryptfs-utils).

:-Dustin

Hi,

I have a question: Does it make any sense to have an encrypted directory and auto-login as well?

Beleriand

Beleriand [2008-11-26 19:51 -0000]:
> I have a question: Does it make any sense to have an encrypted directory
> and auto-login as well?

Sure, if you are fine with unlocking it manually. E. g. you might
store documents there which you don't always need.

However, I use it to store my ssh/gpg keys and Firefox settings, so
for this case it's the right thing to unlock it right on session start
(i. e. I need to log in with password).

That's what I thought, too. And for that reason I think it's a feature not to mount the encrypted directory on login and not a bug.

At least on autologin.

Beleriand [2008-11-27 9:01 -0000]:
> That's what I thought, too. And for that reason I think it's a feature
> not to mount the encrypted directory on login and not a bug.

It *can't* be a bug. If it would be possible to unlock the encrypted
directory fully automatically, then you don't need to encrypt it in
the first place. It would not bring *any* security in that case.

Anyone who can test this and at least confirm that it does not cause any regressions?

I have tested with two accounts, one old and one newly created.
The old account works fine when I login with password. Also manually umounting and mounting Private works fine. However, this account was apparently created before this bug was fixed, so automatic login is hit by comment 60 and 61.

The new account also works fine when I login with password. With automatic login I now get the "Access Your Private Data" symlink and README.txt. Clicking the symlink opens a terminal window asking for my password and then unlocks the Private directory.

All seems fine to me.
(Intrepid, ecryptfs-utils 53-1ubuntu13)

This bug was fixed in the package ecryptfs-utils - 53-1ubuntu13

---------------
ecryptfs-utils (53-1ubuntu13) intrepid-proposed; urgency=low

  Fixes for LP: #259631, add interactive mounting capability
  * debian/rules, debian/ecryptfs-utils.dirs,
    debian/ecryptfs-utils.install, debian/ecryptfs-mount-private.desktop,
    debian/ecryptfs-mount-private.txt: install the new desktop shortcut
    file and readme.txt to /usr/share/ecryptfs-utils
  * debian/patches/60_interactive_mount.dpatch: modify ecryptfs-mount-private
    utility to interactively prompt for password
  * debian/patches/00list: updated accordingly

 -- Dustin Kirkland <email address hidden> Tue, 04 Nov 2008 09:34:41 -0600