[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
** Tags added: verification-done ** Tags removed: verification-needed -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 KirklandTue, 04 Nov 2008 09:34:41 -0600 ** Changed in: ecryptfs-utils (Ubuntu Intrepid) Status: Fix Committed => Fix Released -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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) -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Anyone who can test this and at least confirm that it does not cause any regressions? -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Beleriand [2008-11-27 9:01 -]: > 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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
At least on autologin. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Beleriand [2008-11-26 19:51 -]: > 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). -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Hi, I have a question: Does it make any sense to have an encrypted directory and auto-login as well? Beleriand -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 PROTECTED]> 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, was default previously. ecryptfs-utils (63-1) unstable; urgency=low * Merging upstream version 63. ecryptfs-utils (61-1) unstable; urgency=low * Using patch-stamp rather than patch in rules file. * Merging upstream version 61. * Rediffing sbin-path.dpatch. ecryptfs-utils (58-2) unstable; urgency=low * Adding patch from situert <[EMAIL PROTECTED]> to call ecryptfs helper scripts in /sbin with full path to avoid problem if /sbin is not in PATH (Closes: #498543). ecryptfs-utils (58-1) unstable; urgency=low * Merging upstream version 58. ecryptfs-utils (57-1) unstable; urgency=low * Updating vcs fields in control file. * Merging upstream version 57. ecryptfs-utils (56-1) unstable; urgency=low * Setting permissions for ecryptfs.acc when installing it in rules. * Merging upstream version 56. ecryptfs-utils (55-1) unstable; urgency=low * Merging upstream version 55. ecryptfs-utils (53-2) unstable; urgency=low * Adding auth-client-config support, thanks to Dustin Kirkland <[EMAIL PROTECTED]>. 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 PROTECTED]> Tue, 18 Nov 2008 19:06:54 -0600 ** Changed in: ecryptfs-utils (Ubuntu) Status: Fix Committed => Fix Released -- Cannot open Private directory after a
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
** Changed in: ecryptfs Status: Fix Committed => Fix Released -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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: [EMAIL PROTECTED]:~/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 [EMAIL PROTECTED]:~/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). -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Documented manually adding the symlinks to a legacy-installed encrypted private directory here: https://help.ubuntu.com/community/EncryptedPrivateDirectory :-Dustin -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
One update to my last post... That hack might actually have to go into pam_ecryptfs.so. :-Dustin -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
This -proposed fix worked for me. Be advised that I did not test SSH though. Regards... -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
** Changed in: ecryptfs-utils (Ubuntu) Status: In Progress => Fix Committed -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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. [EMAIL PROTECTED]:~$ /sbin/mount.ecryptfs_private keyctl_search: Required key not available [EMAIL PROTECTED]:~$ keyctl show Session Keyring -3 --alswrv 1000-1 keyring: _uid_ses.1000 202034337 --alswrv 1000-1 \_ keyring: _uid.1000 [EMAIL PROTECTED]:~$ 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. [EMAIL PROTECTED]:~$ 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 [EMAIL PROTECTED]:~$ I hope the proposed fix handles the case of SSH as well. -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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! ** Changed in: ecryptfs-utils (Ubuntu Intrepid) Status: In Progress => Fix Committed ** Tags added: verification-needed -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 (Ubuntu Intrepid) Status: New => In Progress -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
Patch updated to remove 3 lines of non-functional shell code in the new ecryptfs-mount-private script. :-Dustin ** Attachment added: "ecryptfs-utils.259631.debdiff" http://launchpadlibrarian.net/19343367/ecryptfs-utils.259631.debdiff -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 ** Attachment added: "ecryptfs-utils.259631.debdiff" http://launchpadlibrarian.net/19342744/ecryptfs-utils.259631.debdiff -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 ** Attachment added: "ecryptfs-utils.259631.debdiff" http://launchpadlibrarian.net/19342073/ecryptfs-utils.259631.debdiff -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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! -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 ** Changed in: ecryptfs Status: In Progress => Fix Committed -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot when "Automatic Login" enabled
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 ** Also affects: ecryptfs Importance: Undecided Status: New ** Changed in: ecryptfs Importance: Undecided => Medium Assignee: (unassigned) => Dustin Kirkland (kirkland) Status: New => In Progress ** Changed in: ecryptfs-utils (Ubuntu) Importance: Undecided => Medium Status: Confirmed => In Progress ** Attachment added: "ecryptfs-utils.259631.debdiff" http://launchpadlibrarian.net/19315281/ecryptfs-utils.259631.debdiff -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 (Ubuntu) Status: Invalid => Confirmed ** Summary changed: - Cannot open Private directory after a reboot + Cannot open Private directory after a reboot when "Automatic Login" enabled -- Cannot open Private directory after a reboot when "Automatic Login" enabled https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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? -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
My passphrase has an "!" in it... -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
$ 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). -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Well, it still won't mound, I still get: $ mount.ecryptfs_private keyctl_search: Required key not available -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
10 minutes into a reboot, same deal, can't mount it. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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? -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
No. [EMAIL PROTECTED]:~$ crontab -l no crontab for rth [EMAIL PROTECTED]:~$ sudo crontab -l [sudo] password for rth: no crontab for root [EMAIL PROTECTED]:~$ 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 root89 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 root99 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* -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
Rob- Do you have any cronjobs running as your normal user, or as root? $ crontab -l $ sudo crontab -l $ ls -alF /etc/cron* :-Dustin -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
But it's RO. I can't write to it... drwx-- 2 rth rth4096 2008-10-21 11:04 Private drwx-- 2 rth rth4096 2008-10-21 11:04 .Private That should mean that I can write to it. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Odd, now it mounted. I rebooted around 9:30 AM, it's not 1:22 PM and it mounts. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Now it's been a few hours since my last reboot (patches this AM) and it won't mount at all. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
Steve- Any ideas about an arbitrary delay of roughly 5 minutes that PAM might somehow introduce? Rune- Do you have any cronjobs running? :-Dustin -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Dustin, here's the output of the grep command: /etc/pam.d/common-auth:auth optionalpam_ecryptfs.so unwrap /etc/pam.d/common-password:password optionalpam_ecryptfs.so /etc/pam.d/common-session:session optionalpam_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... -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 (Ubuntu) Status: Incomplete => Invalid -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Rob H- Can you check as well? $ grep pam_ecryptfs /etc/pam.d/* :-Dustin -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
** Attachment added: "common-session" http://launchpadlibrarian.net/18812515/common-session -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
** Attachment added: "common-password" http://launchpadlibrarian.net/18812512/common-password -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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-keyring2.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-runtime1.0.1-4ubuntu5 Runtime support for the PAM library ii libpam0g 1.0.1-4ubuntu5 Pluggable Authentication Modules library ii python-pam0.4.2-12ubuntu2 A Python interface to the PAM library ** Attachment added: "common-auth" http://launchpadlibrarian.net/18812503/common-auth -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 [xx...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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
On Tue, Oct 21, 2008 at 10:53 AM, Rune Evjen <[EMAIL PROTECTED]> 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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
> 2. I put in the wrong password, but it succeeded anyway You entered the "wrong" login passphrase twice? :-Dustin -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 259631] Re: Cannot open Private directory after a reboot
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 PROTECTED]> > Rune- > > That "fa5c" 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 > > ** Changed in: ecryptfs-utils (Ubuntu) > Assignee: (unassigned) => Dustin Kirkland (kirkland) > Status: Invalid => Incomplete > > -- > Cannot open Private directory after a reboot > https://bugs.launchpad.net/bugs/259631 > You received this bug notification because you are a direct subscriber > of the bug. > -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
Rune- That "fa5c" 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 ** Changed in: ecryptfs-utils (Ubuntu) Assignee: (unassigned) => Dustin Kirkland (kirkland) Status: Invalid => Incomplete -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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. -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
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 -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 259631] Re: Cannot open Private directory after a reboot
** Summary changed: - Can open Private directory after a reboot + Cannot open Private directory after a reboot -- Cannot open Private directory after a reboot https://bugs.launchpad.net/bugs/259631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
