Bug#516003: segfault caused by umount.crypt after libpam-mount update
Hi, Am Friday 20 February 2009 11:50:48 schrieb Wearenotalone: Yesterday i continued looking for a solution to my problem. At first i changed my volume definition to volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,f sck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,has h=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt path=/my/encrypted.img / Was there a mount error without the changes? The options fsk_cipher and fsk_hash are duplicates of fskeycipher and fskeyhash, so I am wondering why you added them. After this unsatisfactory result i updated libpam-mount to version 1.18 Please test with official Debian packages, unless you want to take this problem to the official mailing list. I will package libpam-mount 1.10 when there is a safe upgrade path for the new cmtab code (ie.a fallback to mtab). But why is a loop device attached to my LUKS partition? Is it not enough if only the LUKS partition is mounted and not another loop device on top of it? What is your exact setup after mounting? I assume the following /my/encrypted.img (loop) /dev/loop0 (luks) /dev/mapper/_my_enrypted_img (loop) /dev/loop1 If this is the case, the second /dev/loop1 mount is indeed unneeded. At the moment i am searching for the place in the sources where the (second) loop device (/dev/loop1) is attached to my LUKS partition. Do you have a hint where i could search? Is this only occuring in the 1.18 codebase, or in 1.10 also? Regards, Bastian signature.asc Description: This is a digitally signed message part.
Bug#516003: segfault caused by umount.crypt after libpam-mount update
Hello, Bastian Kleineidam schrieb: Hi, Am Friday 20 February 2009 11:50:48 schrieb Wearenotalone: Yesterday i continued looking for a solution to my problem. At first i changed my volume definition to volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,f sck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,has h=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt path=/my/encrypted.img / Was there a mount error without the changes? The options fsk_cipher and fsk_hash are duplicates of fskeycipher and fskeyhash, so I am wondering why you added them. These entries are leftovers from my unsuccessful attempt to use the fsk_hash option with libpam_mount 0.44-1+lenny3. At the moment i use this config for version 1.9, 1.10 and 1.18: volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt/tmp1 path=/my/encrypted.img fstype=crypt / With version libpam-mount 1.9 and the keybits=256 option set, i get a segfault everytime i log out. Without the keybits option, everything seems to be fine. With the newest libpam-mount 1.10 it is still the same. After this unsatisfactory result i updated libpam-mount to version 1.18 Please test with official Debian packages, unless you want to take this problem to the official mailing list. I will package libpam-mount 1.10 when there is a safe upgrade path for the new cmtab code (ie.a fallback to mtab). Ok, i just wanted to inform you that the segfault is gone with the newest version. But even if this segfault is gone, the problems (unmount not successful / loop device on top of LUKS partition) still exist. For future tests i set up a VM with Debian so that i can test different libpam-mount packages without risking data loss. The previously mentioned tests in this mail (libpam-mount 1.9 and 1.10) were carried out in this VM (got the same results with my regular system before). But why is a loop device attached to my LUKS partition? Is it not enough if only the LUKS partition is mounted and not another loop device on top of it? What is your exact setup after mounting? I assume the following /my/encrypted.img (loop) /dev/loop0 (luks) /dev/mapper/_my_enrypted_img (loop) /dev/loop1 If this is the case, the second /dev/loop1 mount is indeed unneeded. With keybits option and libpam-mount 1.10 ( before logout ): $ losetup -a /dev/loop0: [0801]:441553 (/my/encrypted.img) /dev/loop1: [000d]:23903 (/dev/mapper/_my_encrypted_img) $ mount | grep /my/encrypted.img /my/encrypted.img on /mnt/tmp1 type crypt (keybits=256,noexec,nodev,nosuid,relatime) $ cat /etc/mtab | grep /my/encrypted.img /my/encrypted.img /mnt/tmp1 crypt keybits=256,noexec,nodev,nosuid,relatime 0 0 $ tail -n 28 /var/log/all Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:312): pam_mount 1.10: entering auth stage Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_unix(login:session): session opened for user MYUSERNAME by LOGIN(uid=0) Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:458): pam_mount 1.10: entering session stage Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:479): back from global readconfig Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:481): per-user configurations not allowed by pam_mount.conf.xml Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(misc.c:38): Session open: (uid=0, euid=0, gid=1000, egid=1000) Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(rdconf2.c:182): checking sanity of volume record (/my/encrypted.img) Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:536): about to perform mount operations Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:181): Mount info: globalconf, user=MYUSERNAME volume server=(null) path=/my/encrypted.img mountpoint=/mnt/tmp1 cipher=(null) fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc fskeyhash=sha512 options=keybits=256,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256 / fstab=0 Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount-sysv.c:57): realpath of volume /mnt/tmp1 is /mnt/tmp1 Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount-sysv.c:61): checking to see if /my/encrypted.img is already mounted at /mnt/tmp1 Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:494): checking for encrypted filesystem key configuration Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:497): about to start building mount command Feb 24 18:09:34 MYHOSTNAME login[5707]: command: [mount.crypt] [-ofsk_cipher=aes-256-cbc] [-ofsk_hash=sha512] [-okeyfile=/my/encrypted.key] [-okeybits=256,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256] [/my/encrypted.img] [/mnt/tmp1] Feb 24 18:09:34 MYHOSTNAME login[5723]: pam_mount(misc.c:38):
Bug#516003: segfault caused by umount.crypt after libpam-mount update
Am Tuesday 24 February 2009 18:45:30 schrieb Wearenotalone: Anymore questions? Not at the moment. Your information should be enough to reproduce the problem, which I will try to do in the next days. Thanks, Bastian signature.asc Description: This is a digitally signed message part.
Bug#516003: segfault caused by umount.crypt after libpam-mount update
Yesterday i continued looking for a solution to my problem. At first i changed my volume definition to volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt path=/my/encrypted.img / The next time when I logged on to tty2, I got this error message: # LOGIN: Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:312): pam_mount 1.9: entering auth stage Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_unix(login:session): session opened for user MYUSERNAME by LOGIN(uid=0) Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:458): pam_mount 1.9: entering session stage Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:479): back from global readconfig Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:481): per-user configurations not allowed by pam_mount.conf.xml Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(misc.c:38): Session open: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(rdconf2.c:182): checking sanity of volume record (/my/encrypted.img) Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:536): about to perform mount operations Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount.c:181): Mount info: globalconf, user=MYUSERNAME volume server=(null) path=/my/encrypted.img mountpoint=/mnt cipher=(null) fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 / fstab=0 Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount-sysv.c:57): realpath of volume /mnt is /mnt Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount-sysv.c:61): checking to see if /my/encrypted.img is already mounted at /mnt Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount.c:494): checking for encrypted filesystem key configuration Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount.c:497): about to start building mount command Feb 19 20:17:04 MYHOSTNAME login[4099]: command: [mount] [-p0] [-o] [fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512] [-t] [auto] [/my/encrypted.img] [/mnt] Feb 19 20:17:04 MYHOSTNAME login[4278]: pam_mount(misc.c:38): set_myuidpre: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:04 MYHOSTNAME login[4278]: pam_mount(misc.c:38): set_myuidpost: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount.c:75): mount errors: Feb 19 20:17:04 MYHOSTNAME login[4099]: pam_mount(mount.c:78): mount.crypt_LUKS(mtcrypt.c:155): loop mount option ignored Feb 19 20:17:06 MYHOSTNAME login[4099]: pam_mount(mount.c:78): Command successful. Feb 19 20:17:06 MYHOSTNAME kernel: [ 513.219718] kjournald starting. Commit interval 5 seconds Feb 19 20:17:06 MYHOSTNAME kernel: [ 513.220175] EXT3 FS on loop1, internal journal Feb 19 20:17:06 MYHOSTNAME kernel: [ 513.220273] EXT3-fs: mounted filesystem with ordered data mode. Feb 19 20:17:06 MYHOSTNAME login[4099]: pam_mount(mount.c:539): waiting for mount Feb 19 20:17:06 MYHOSTNAME login[4099]: command: [pmvarrun] [-u] [MYUSERNAME] [-o] [1] Feb 19 20:17:06 MYHOSTNAME login[4328]: pam_mount(misc.c:38): set_myuidpre: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:06 MYHOSTNAME login[4328]: pam_mount(misc.c:38): set_myuidpost: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:06 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:418): pmvarrun says login count is 1 Feb 19 20:17:06 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:550): done opening session (ret=0) #LOGOUT: Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_unix(login:session): session closed for user MYUSERNAME Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:592): received order to close things Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_mount(misc.c:38): Session close: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:17 MYHOSTNAME login[4099]: command: [pmvarrun] [-u] [MYUSERNAME] [-o] [-1] Feb 19 20:17:17 MYHOSTNAME login[4352]: pam_mount(misc.c:38): set_myuidpre: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:17 MYHOSTNAME login[4352]: pam_mount(misc.c:38): set_myuidpost: (uid=0, euid=0, gid=1000, egid=1000) Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_mount(pam_mount.c:418): pmvarrun says login count is 0 Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_mount(mount.c:673): going to unmount Feb 19 20:17:17 MYHOSTNAME login[4099]: pam_mount(mount.c:181): Mount info: globalconf, user=MYUSERNAME volume server=(null) path=/my/encrypted.img mountpoint=/mnt cipher=(null) fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc fskeyhash=sha512
Bug#516003: segfault caused by umount.crypt after libpam-mount update
I think i have identified the cause of my unmount problem. The mount option keybits implies the loop option. This causes the LUKS partition again to be mounted as a loop device. At the moment mount.crypt only filters the loop option but not the keybits option. Usualy this is no problem because the regular mount command writes the newly created loop device (the second one) to /etc/mtab (e.g. loop=/dev/loop1) and /proc/mounts. With the help of the -d option of umount the loop device is properly detached. But at the moment mount.crypt (up from version 1.16) does not use /etc/mtab and /proc/mounts or at least is not able to detach the loop device. A simple insertion of umount_args[argk++] = -d; to the function mtcr_umount(...) in mtcrypt.c is not enough. The result of this shortcoming is that the LUKS partition is successfully unmounted but cannot be closed because there is still a open loop device left (/dev/loop1). Because of that i can think of two solutions. The first one is to ignore the keybits option as we do with the loop option. The following patch for version 1.18 does this: --- src/mtcrypt.c.old 2009-02-07 12:42:49.0 +0100 +++ src/mtcrypt.c 2009-02-20 18:28:23.0 +0100 @@ -158,6 +158,8 @@ l0g(keysize mount option ignored\n); else if (strcmp(key, fsck) == 0) mo-fsck = true; + else if (strcmp(key, keybits) == 0) + l0g(keybits mount option ignored\n); else if (strcmp(key, loop) == 0) /* automatically detected anyway */ l0g(loop mount option ignored\n); The second way is to save any mount option to /etc/cmtab (in particular the loop=/dev/loop1 option) and then to properly detach the second loop device before luksClosing the LUKS partition. But this requires a little bit more work and should be done by someone with more linux and c development experience. Of course the easiest solution would be not to use the keybits option at all. But nowhere is any hint that the user may not select this option, so nobody knows. Besides that i informed the developer of pam-mount (jengelh) about this bug report. It would be very nice if someone could give me some feedback on this. Best regards, WANA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: segfault caused by umount.crypt after libpam-mount update
The first solution seems to be incomplete. If the keybits option is given then the loop device (/dev/loop1) on top of the LUKS partition is not created (correct behavior), BUT the loop device of the /my/encrypted.img file (/dev/loop0) is not removed after luksClosing /dev/mapper/_my_encrypted_img! The result of this is that at every login a new loop device is attached to the /my/encrypted.img but not removed after logout. Thats not nice. If you dont use the keybits option then everything is properly unmounted/luksClosed/detached. While playing around with version 1.18 i also noticed that not specifing an keyfile option (not fskeypath=, but keyfile option in options=!) causes LUKS to drop this message: pam_mount(mount.c:67): Command failed: No key available with this passphrase. But i will investigate this later and probably open another bugreport. Best Regards, WANA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: segfault caused by umount.crypt after libpam-mount update
Package: libpam-mount Version: 1.9-1 Severity: important After upgrading libpam-mount from the latest Debian Lenny version (0.44-1+lenny3) to the latest Squeeze version (1.9-1) i get a segfault from umount.crypt everytime i logout. The encrypted directory is successfully unmounted, but i get this messages when logging out from tty1: pam_mount(mount.c:78): Command failed. [ 795.998232] umount.crypt[4650]: segfault at ed ip b7e5738b sp bffd3518 error 4 in libc-2.7.so[b7de1000+155000] pam_mount(mount.c:676): unmount of /my/encrypted.img failed Also the loop devices are not properly detached: $losetup -a /dev/loop0: [0901]:14450726 (/my/encrypted.img) /dev/loop1: [000d]:11227 (/dev/mapper/_my_encrypted_img) After the segfault from mount.crypt i am not able to log in again, until i did this: losetup -d /dev/loop1 cryptsetup luksClose /dev/mapper/_my_encrypted_img losetup -d /dev/loop0 In /etc/security/pam_mount.conf.xml i only changed debug to 1 and added the following line: volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt/ path=/my/encrypted.img fstype=crypt / Has anyone an idea how to solve this problem? Best Regards, WANA -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (650, 'testing'), (500, 'proposed-updates'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-wana081 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpam-mount depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libhx182.3-1 A library providing queue, tree, I ii libpam0g 1.0.1-5 Pluggable Authentication Modules l ii libssl0.9.80.9.8g-15 SSL shared libraries ii libxml22.6.32.dfsg-5 GNOME XML library ii mount 2.13.1.1-1Tools for mounting and manipulatin libpam-mount recommends no packages. Versions of packages libpam-mount suggests: ii cryptsetup 2:1.0.6-7 configures encrypted block devices pn davfs2 none(no description available) ii fuse-utils 2.7.4-1.1 Filesystem in USErspace (utilities ii lsof 4.78.dfsg.1-4 List open files pn ncpfs none(no description available) ii openssl0.9.8g-15 Secure Socket Layer (SSL) binary a ii psmisc 22.6-1Utilities that use the proc filesy ii smbfs 2:3.2.5-4 mount and umount commands for the pn truecrypt-utilsnone(no description available) pn xfsprogs none(no description available) -- debconf information: * libpam-mount/convert-xml-config: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
