I ran Lubuntu 10.10 in a virtualbox VM, added a user with an encrypted
home directory and demonstrated the original bug. Enabled -proposed,
updated the world, rebooted the VM, and verified I can now access that
encrypted home directory immediately after login.
Since I am running virtualbox-ose I cannot test the USB stick mount
issues relating to libpam-ck-connector directly. I confirm the proposed
lxdm package as a Conflicts: libpam-ck-connector entry, but that's as
far as I can go with testing that.
However, there is *another* rather nasty encryption-related issue that
appears, and I am not sure whether it is related to this fix or not:
after doing all the above (installed Lubuntu, update it, add a user with
an encrypted home, add -proposed to sources, update and upgrade, reboot,
verify encrypted home user now automounts his home), it seems that apt-
get autoremove tries to remove packages it should be leaving well alone:
sudo apt-get autoremove -s
[sudo] password for jonathan:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
cryptsetup dmraid ecryptfs-utils keyutils libdebconfclient0
libdmraid1.0.0.rc16 libecryptfs0 linux-headers-2.6.35-22
linux-headers-2.6.35-22-generic localechooser-data ndiswrapper-common
python-pyicu python-webkit rdate reiserfsprogs
0 upgraded, 0 newly installed, 15 to remove and 0 not upgraded.
If a real (not simulated) apt-get remove is attempted after the user
with the encrypted home has logged in, bad things happen:
The following packages will be REMOVED:
cryptsetup dmraid ecryptfs-utils keyutils libdebconfclient0
libdmraid1.0.0.rc16 libecryptfs0 linux-headers-2.6.35-22
linux-headers-2.6.35-22-generic localechooser-data ndiswrapper-common
python-pyicu python-webkit rdate reiserfsprogs
0 upgraded, 0 newly installed, 15 to remove and 21 not upgraded.
After this operation, 94.4MB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 97781 files and directories currently installed.)
Removing cryptsetup ...
update-initramfs: deferring update (trigger activated)
Removing dmraid ...
update-initramfs: deferring update (trigger activated)
Removing ecryptfs-utils ...
ERROR: Cannot remove ecryptfs-utils, as it appears to be in use:
[/home/eh/.ecryptfs]
dpkg: error processing ecryptfs-utils (--remove):
subprocess installed pre-removal script returned error exit status 1
Removing libdebconfclient0 ...
Removing libdmraid1.0.0.rc16 ...
Removing linux-headers-2.6.35-22-generic ...
Removing linux-headers-2.6.35-22 ...
Removing localechooser-data ...
Removing ndiswrapper-common ...
Removing python-pyicu ...
Removing python-webkit ...
Removing rdate ...
Removing reiserfsprogs ...
dpkg: keyutils: dependency problems, but removing anyway as you requested:
ecryptfs-utils depends on keyutils; however:
Package keyutils is to be removed.
Removing keyutils ...
dpkg: libecryptfs0: dependency problems, but removing anyway as you requested:
ecryptfs-utils depends on libecryptfs0 (>= 77); however:
Package libecryptfs0 is to be removed.
Removing libecryptfs0 ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.35-25-generic
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for python-support ...
Errors were encountered while processing:
ecryptfs-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)
Now autoremove just broke our dependencies, we have ecryptfs-utils
installed but not some of its dependencies keyutils and libecryptfs0 !
This is not supposed to happen!
At this point, logging back in as the user with the encrypted home
directory (user eh in my test, EH stands for Encrypted Home!) no longer
mounts his directory, and worse yet, trying to mount it manually
generates an error
ecryptfs-mount-private
Enter your login passphrase:
ecryptfs-insert-wrapped-passphrase-into-keyring: error while loading shared
libraries: libecryptfs.so.0: cannot open shared object file: No such file or
directory
ERROR: Your passphrase is incorrect
Enter your login passphrase:
I rather doubt the proposed change to lxdm is responsible for this mess,
but... the end result after installing the updated lxdm and then doing
apt-get autoremove is *very* bad. My strong suspicion is that something
does not depend on ecryptfs-utils that really *needs* to depend on them.
Sorry I couldn't provide a clean green light verification, I hope this
information is useful in looking further at this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/635698
Title:
encrypted home-folder not unlocked when login
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
