Cannot open Private directory after a reboot when "Automatic Login" enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
Medium
|
Dustin Kirkland | ||
ecryptfs-utils (Ubuntu) |
Fix Released
|
Medium
|
Dustin Kirkland | ||
Intrepid |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: ecryptfs-utils
I created an encrypted private directory following the instructions here:
https:/
Everything worked as it should until I rebooted. When I try to mount my private directory I get the following message:
jimk@intrepid:~$ mount.ecryptfs_
keyctl_search: Required key not available
When I go to create a key, I get the following message:
jimk@intrepid:~$ ecryptfs-
ERROR: wrapped-passphrase file already exists, use --force to overwrite.
I can create a new passphrase if I use the force option, but I shouldn't have to do this everytime I reboot
Related branches
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] [NEW] Can open Private directory after a reboot | #1 |
cariboo (cariboo) wrote : Re: Can open Private directory after a reboot | #2 |
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.
cariboo (cariboo) wrote : | #3 |
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_
Umount script:
#!/bin/sh
umount.
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Can open Private directory after a reboot | #4 |
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_
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
cariboo (cariboo) wrote : Re: Can open Private directory after a reboot | #5 |
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
Dustin Kirkland (kirkland) wrote : | #6 |
Thanks!!!
Changed in ecryptfs-utils: | |
status: | New → Invalid |
Rune Evjen (rune-evjen) wrote : | #7 |
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
Dustin Kirkland (kirkland) wrote : | #8 |
Please attempt to run:
$ ecryptfs-
And see if that utility is able to unwrap your mount passphrase.
:-Dustin
Claudiu Vlad (claudiu-vlad) wrote : | #9 |
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_
Executing "ecryptfs-
Rune Evjen (rune-evjen) wrote : | #10 |
Dustin,
ecryptfs-
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.
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
Dustin Kirkland (kirkland) wrote : | #11 |
Did you run ecryptfs-
When you run 'ecryptfs-
Make sure you quote your login passphrase if you have any funny characters.
:-Dustin
Rune Evjen (rune-evjen) wrote : Re: Cannot open Private directory after a reboot | #12 |
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-
"Unable to read salt value from user's .ecryptfsrc file; using default fa0ec2dfef0ab60
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
Dustin Kirkland (kirkland) wrote : | #13 |
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/
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.
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-
Once you're able to successfully decrypt ~/.ecryptfs/
Now that you have the passphrase in the keyring, you should be able to mount your encrypted private directory with 'mount.
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_
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
Changed in ecryptfs-utils: | |
assignee: | nobody → kirkland |
status: | Invalid → Incomplete |
Rob H (r-robh) wrote : | #14 |
I seem to have the same problem. Here's what I did:
1. I ran ecryptfs-
2. I put in the wrong password, but it succeeded anyway
3. I tried to rerun ecryptfs-
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-
7. I typed in my own passphrase during setup, Private.sig and 'keyctl show' do return the same value.
Rune Evjen (rune-evjen) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #15 |
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/
> 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.
> 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-
> 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-
> 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-
> 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/
> (and please don't post your passphrases here), run
> 'ecryptfs_
> 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.
>
> If you're still getting "keyctl_search: Required key not available",
> then the wrong passphrase has been inserted into your...
Dustin Kirkland (kirkland) wrote : | #16 |
> 2. I put in the wrong password, but it succeeded anyway
You entered the "wrong" login passphrase twice?
:-Dustin
Dustin Kirkland (kirkland) wrote : | #17 |
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-
If you can decrypt it using ecryptfs-
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-
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
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #18 |
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.
Rune Evjen (rune-evjen) wrote : | #19 |
Test Result
1. First, you need to figure out if you can decrypt your mount_passphrase, using 'ecryptfs-
Result: Received salt warning, command printed the hex digits and returned 0
2. Once you're able to successfully decrypt ~/.ecryptfs/
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_
4. Now that you have the passphrase in the keyring, you should be able to mount your encrypted private directory with 'mount.
Result: Using the 'mount.
5. Reboot persistency
After applying the above commands and accessing ~/Private, I rebooted and ran 'mount.
'keyctl show' does not list my key, only my "old" key (see 3).
After adding it with 'ecryptfs-
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
Dustin Kirkland (kirkland) wrote : | #20 |
Rune-
Cool, thanks for the details. Multiple keys in the keyring should be fine. The file ~/.ecryptfs/
It sounds like your PAM configuration isn't correct.
Could you please post /etc/pam.
Also, could you indulge me with your ecryptfs and pam versions?
$ dpkg -l | grep ecryptfs
$ dpkg -l | grep pam
:-Dustin
Rob H (r-robh) wrote : | #21 |
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.
Rob H (r-robh) wrote : | #22 |
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.
Rune Evjen (rune-evjen) wrote : | #23 |
- common-auth Edit (524 bytes, text/plain)
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-
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
Rune Evjen (rune-evjen) wrote : | #24 |
Rune Evjen (rune-evjen) wrote : | #25 |
Steve Langasek (vorlon) wrote : | #26 |
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.
Dustin Kirkland (kirkland) wrote : | #27 |
Rob H-
Can you check as well?
$ grep pam_ecryptfs /etc/pam.d/*
:-Dustin
Rune Evjen (rune-evjen) wrote : | #28 |
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
Dustin Kirkland (kirkland) wrote : | #29 |
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
Changed in ecryptfs-utils: | |
status: | Incomplete → Invalid |
Rob H (r-robh) wrote : | #30 |
Dustin, here's the output of the grep command:
/etc/pam.
/etc/pam.
/etc/pam.
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...
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #31 |
Steve-
Any ideas about an arbitrary delay of roughly 5 minutes that PAM might
somehow introduce?
Rune-
Do you have any cronjobs running?
:-Dustin
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #32 |
Now it's been a few hours since my last reboot (patches this AM) and it won't mount at all.
Rob H (r-robh) wrote : | #33 |
Odd, now it mounted. I rebooted around 9:30 AM, it's not 1:22 PM and it mounts.
Rob H (r-robh) wrote : | #34 |
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.
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #35 |
Rob-
Do you have any cronjobs running as your normal user, or as root?
$ crontab -l
$ sudo crontab -l
$ ls -alF /etc/cron*
:-Dustin
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #36 |
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*
Steve Langasek (vorlon) wrote : | #37 |
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?
Rob H (r-robh) wrote : | #38 |
10 minutes into a reboot, same deal, can't mount it.
Rob H (r-robh) wrote : | #39 |
Well, it still won't mound, I still get:
$ mount.ecryptfs_
keyctl_search: Required key not available
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #40 |
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/
If that key signature is missing, or two two do not match, that's
where we need to start debugging this problem.
:-Dustin
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #41 |
$ keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
404603209 --alswrv 1000 -1 \_ keyring: _uid.1000
$ cat ~/.ecryptfs/
[removed]
Not the same... I recall doing this before and they did match (see earlier in this thread).
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #42 |
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
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #43 |
My passphrase has an "!" in it...
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #44 |
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-
* https:/
You will need to upgrade to this newer version of ecryptfs-utils, and
then you'll need to re-run "ecryptfs-
that, you might need to move any data you currently have out of
~/Private.
:-Dustin
Rob H (r-robh) wrote : Re: Cannot open Private directory after a reboot | #45 |
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?
Rob H (r-robh) wrote : | #46 |
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.
ubuntostones (spamgoat) wrote : | #47 |
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_
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.
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot | #48 |
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
Dustin Kirkland (kirkland) wrote : Re: Cannot open Private directory after a reboot | #49 |
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
Changed in ecryptfs-utils: | |
status: | Invalid → Confirmed |
Dustin Kirkland (kirkland) wrote : | #50 |
- ecryptfs-utils.259631.debdiff Edit (10.6 KiB, text/plain)
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
Changed in ecryptfs: | |
assignee: | nobody → kirkland |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in ecryptfs-utils: | |
importance: | Undecided → Medium |
status: | Confirmed → In Progress |
Dustin Kirkland (kirkland) wrote : | #51 |
Fix committed to upstream git repository:
* http://
Will be released in version 64.
:-Dustin
Changed in ecryptfs: | |
status: | In Progress → Fix Committed |
Martin Pitt (pitti) wrote : | #52 |
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/
* Minor gotcha: You install ecryptfs-
* debian/
Many thanks for working on this!
Dustin Kirkland (kirkland) wrote : | #53 |
- ecryptfs-utils.259631.debdiff Edit (10.5 KiB, text/plain)
Updated patch attached, per Martin's comments.
Upstream commit:
* http://
:-Dustin
Dustin Kirkland (kirkland) wrote : | #54 |
- ecryptfs-utils.259631.debdiff Edit (10.5 KiB, text/plain)
Stable Release Update Request
Per:
* https:/
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-
"README.txt" in a user's unmount encrypted ~/Private directory
* src/desktop/
to be installed in each user's unmounted Private dir, providing a
clickable way to mount (tested in Gnome and KDE)
* src/utils/
into the unmount Private dir
* src/utils/
interactively prompt for a user's login password, unwrap the mount
passphrase and insert into the keyring, and perform the mount
* src/utils/
deprecated (and broken) counter mechanism, and very simply call
umount.
* src/utils/
key isn't found, that perhaps they user wants to try the interactive
ecryptfs-
* See: http://
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-
d) mount.ecryptfs_
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-
:-Dustin
Dustin Kirkland (kirkland) wrote : | #55 |
- ecryptfs-utils.259631.debdiff Edit (10.3 KiB, text/plain)
Patch updated to remove 3 lines of non-functional shell code in the new ecryptfs-
:-Dustin
Martin Pitt (pitti) wrote : | #56 |
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.
Changed in ecryptfs-utils: | |
status: | New → In Progress |
Martin Pitt (pitti) wrote : | #57 |
Accepted into intrepid-proposed, please test and give feedback here. Please see https:/
Changed in ecryptfs-utils: | |
status: | In Progress → Fix Committed |
Charles Curley (charlescurley) wrote : | #58 |
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.
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.
Changed in ecryptfs-utils: | |
status: | In Progress → Fix Committed |
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote : | #59 |
This -proposed fix worked for me. Be advised that I did not test SSH though. Regards...
Martin Pitt (pitti) wrote : | #60 |
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_
There was no "readme.txt" file as I would have expected from the debdiff. Also, running this script (or mount.ecryptfs_
So this doesn't work for me.
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled | #61 |
Martin-
The fix, as proposed, will only solve this comprehensively for *newly*
created encrypted-private setups, with the patched
ecryptfs-
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-
existence of these links in an unmounted Private dir, and create them
just before mounting.
Is that what you'd want?
:-Dustin
Dustin Kirkland (kirkland) wrote : | #62 |
One update to my last post... That hack might actually have to go
into pam_ecryptfs.so.
:-Dustin
Martin Pitt (pitti) wrote : | #63 |
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.
Dustin Kirkland (kirkland) wrote : | #64 |
Documented manually adding the symlinks to a legacy-installed
encrypted private directory here:
https:/
:-Dustin
Tommaso R. Donnarumma (tawmas) wrote : | #65 |
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@
ecryptfs-utils:
Installed: 53-1ubuntu12
Candidate: 53-1ubuntu12
Version table:
*** 53-1ubuntu12 0
500 http://
100 /var/lib/
tawmas@
ls: cannot access /usr/share/
(I just upgraded to Jaunty, but had already tested SSH access on Intrepid, with intrepid-proposed enabled and all upgrades applied).
Changed in ecryptfs: | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #66 |
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/
- 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/
(Bug: #506172)
- debian/control:
+ keep the dpatch build dep
+ depend on libpam-runtime (Bug: #506172)
- debian/
(Bug: #506172)
- debian/
private dir (Bug: #506172)
- debian/
unmounted private dir (Bug: #506172)
- debian/
- debian/
(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_
license (GPL-2+).
* Building without pkcs11 helper, ecryptfs_
links against openssl and has incompatible license (GPL-2+).
* Building without pkcs11 helper, ecryptfs_
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-
package installation time.
ecryptfs-utils (65-1) unstable; urgency=low
* Merging upstream version 65:
- Adds --wrapping option to ecryptfs-
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-
(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/
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, ...
Changed in ecryptfs-utils: | |
status: | Fix Committed → Fix Released |
Jim (jdblaich) wrote : | #67 |
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_
doesn't work for me. I have to replace the underscores in the command to be hypens, so the following command works:
ecryptfs-
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-
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_
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.
Martin Pitt (pitti) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled | #68 |
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.
am28111 (am28111) wrote : | #69 |
I still an unable to mount the private directory. When I run 'ecryptfs_
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-
I guess everything is working fine but somehow I am still unable to mount it. Help is much appreciated.
Dustin Kirkland (kirkland) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled | #70 |
Jim-
I have posted instructions at:
* https:/
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
Dustin Kirkland (kirkland) wrote : | #71 |
am28111-
* The "salt value" messages are merely warnings, and are benign, and
will not cause a problem.
* The "ecryptfs_
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
am28111 (am28111) wrote : | #72 |
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:/
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.
Dustin Kirkland (kirkland) wrote : | #73 |
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
Oliver Horn (oliverhorn) wrote : | #74 |
Hi,
I have a question: Does it make any sense to have an encrypted directory and auto-login as well?
Beleriand
Martin Pitt (pitti) wrote : Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled | #75 |
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).
Oliver Horn (oliverhorn) wrote : | #76 |
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.
Oliver Horn (oliverhorn) wrote : | #77 |
At least on autologin.
Martin Pitt (pitti) wrote : | #78 |
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.
Martin Pitt (pitti) wrote : | #79 |
Anyone who can test this and at least confirm that it does not cause any regressions?
Albert Damen (albrt) wrote : | #80 |
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)
Launchpad Janitor (janitor) wrote : | #81 |
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/
debian/
debian/
file and readme.txt to /usr/share/
* debian/
utility to interactively prompt for password
* debian/
-- Dustin Kirkland <email address hidden> Tue, 04 Nov 2008 09:34:41 -0600
Changed in ecryptfs-utils: | |
status: | Fix Committed → Fix Released |
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