Bugzilla – Bug 671276
pam_mount leaves stuff in /dev/mapper and does not unmount encrypted partitions
Last modified: 2011-09-06 16:17:53 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b11) Gecko/20110203 Firefox/4.0b11 I am using a home partition that is encrypted with LUKS. A passphrase is used to authenticate and the volume is automaticaly mounted at login through pam_mount. After upgrading fom oS 11.3 to oS 11.4 RC1 this does not work correct anymore. The first login works, but when I logout and then try to login, pam_mount prints only some error logs and does not mount the volume again. The reason is that the partition is not unmounted from device mapper. The mountpoint (/dev/mapper/_dev_sda3 -> /home) is cleaned from mtab, but _dev_sda3 is still present in /dev/mapper. When I close the LUKS volume manually with cryptsetup luksClose _dev_sda3 /dev/mapper is clean and I can use pam_mount again... Till the next logout. When I mount it manually with mount.crypt and than try to unmount it with umount.crypt, umount.crypt tells me, that it is not mounted - but it is. #~ mount.crypt /dev/sda3 /home Password: That works. #~ umount.crypt /home /home is not mounted (according to cmtab) After mount.crypt /var/run/cmtab contains the information. But after using umount.crypt cmtab is empty. The mountpoint still is in /etc/mtab and the partition ist still correctly mounted. I can unmount it completely manual by using umount and cryptsetup. Reproducible: Always Steps to Reproduce: 1. Having a LUKS formatted and encryptet partition /dev/sda3, want to mount it on /home 2. mount.crypt /dev/sda3 /home 3. Entering password, all works, partition is mounted. 4. umount.crypt /home prints /home is not mounted (according to cmtab) Actual Results: Partition gets not unmounted or is still under /dev/mapper as _dev_sda3. Expected Results: Partition should be unmounted completely, from /home and from /dev/mapper/_dev_sda3. This setup was created manually in openSUSE 11.3, without YaST, and worked properly there.
This is a problem with util-linux 2.19-rc and with the fact that distros choose to make /etc/mtab a symlink to /proc/mounts. Previously, mount.crypt put "crypt" as an fstype into mtab, so that umount.crypt is called when umount(8) is run. With the symlink and the readonly /proc/mounts, this no longer works. Upstream maintainer Karel Zak says to use the "uhelper" option during mounting, however this mechanism is broken too: umount won't call the helper when root does the umount. References: https://sourceforge.net/support/tracker.php?aid=3162979
Any news on this? What I am not quite understanding: On a console logout, the partition gets umounted here, just the /dev/mapper/_dev_xxx remains (on X logout the partition does not get umounted). So if pam_mount knows that it should umount /my/mount/target in general, it should not be so hard to figure out which /dev/mapper/_dev_xxx device corresponds to /my/mount/target and make pam_mount call "cryptsetup luksClose _dev_xxx". Anyways, a fix would be greatly appreciated. The lack of a working pam_mount for LUKS makes me quite unhappy at the moment.
There are some fixed in pam_mount 2.10. If you like, you can also try an util-linux and pam_mount snapshot which now use libmount to track extra attributes.
Thank you for your feedback. I tried the pam_mount 2.10 package provided by your home:jengelh:dev repository at the Open Build Service once without and once with the util-linux 2.19.90 package provided by the same repository on openSUSE 11.4/x86_64. I activated pam_mount in /etc/pam.d/login and logged in at the login shell. The result was the same both with and without using the updated util-linux package: - The main issue stills persists: The /dev/mapper/_sdXY dm-crypt device survives the logout and the subsequent login attempt does not mount the encrypted partition again, saying the dm-crypt device cannot be created because it already exists. - Additionally for some reason the mount point of the home directory gets removed at logout, so at the subsequent login there is an additional error saying that the mount point does not exist. - During the subsequent login the dm-crypt device in /dev/mapper gets removed (this seems to be new), so the following login works again (magically also the mount point reappears). In short: Login attempts No 1, 3, 5... work and login attempts No 2, 4, 6... do not work (but remove the dm-crypt device, so the following unevenly numbered login works again). Also there is a new big fat warning message saying that umounting won't work if /etc/mtab is not writable. In my case umounting works, but just the removal of the dm-crypt device at logout does not. If the problem is just that pam_mount can't remember which dm-crypt device it has to remove: Couldn't this be easily solved by pam_mount saving that information at login somewhere in /var? Thanks in advance for looking into it!
I forgot to commit the new pam_mount (fictional version 2.90), now done so.
Using the new version you provided, pam_mount does not work anymore at all (with as well as without the updated util-linux package). When I was trying it on a login shell, the status messages vanished too quickly to write them down, so here is the result of using pam_mount with su instead: pam_mount(pam_mount.c:553): pam_mount 2.10: entering session stage reenter password for pam_mount: pam_mount(misc.c:38): Session open: (ruid/rgid=0/0, e=0/0) pam_mount(mount.c:260): Mount info: globalconf, user=tittel <volume fstype="crypt" server="(null)" path="/dev/sdb9" mountpoint="/home/tittel" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="noatime,acl" /> fstab=0 ssh=0 Segmentation fault I am using the following configuration line for the mount in /etc/security/pam_mount.conf.xml: <volume options="noatime,acl" user="tittel" mountpoint="/home/tittel" path="/dev/sdb9" fstype="crypt"/> Thanks again for checking it out.
Jan. I think it would be a good idea, if you would take over this bug.
(In reply to comment #6) > Using the new version you provided, pam_mount does not work anymore at all > (with as well as without the updated util-linux package). > > When I was trying it on a login shell, the status messages vanished too quickly > to write them down, so here is the result of using pam_mount with su instead: > > pam_mount(mount.c:260): Mount info: globalconf, user=tittel <volume > fstype="crypt" server="(null)" path="/dev/sdb9" mountpoint="/home/tittel" > cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" > options="noatime,acl" /> fstab=0 ssh=0 > Segmentation fault This looks like it killed su, without giving you the new shell, so that would be some bug in the module. Will look. Does using mount.crypt directly work for your case w.r.t. leaving devices in /dev/mapper?
ping
I have similar situation. umount.crypt does not unmount the mounted file system. /home/pavel # umount.crypt -f /home/pavel/containercontents /home/pavel/containercontents is not mounted (according to cmtab)
As a workaround, I use script /usr/local/sbin/unmountLuks: #!/bin/sh cryptDevice=`grep "$1" /etc/mtab | cut -d "/" -f 4` umount "$1" loDevice=`dmsetup ls | grep "$cryptDevice" | cut -d "," -f 2 | cut -d ")" -f 1 | tr -dc [:digit:]` cryptsetup luksClose $cryptDevice losetup -d /dev/loop$loDevice And modified pam_mount.so to use the script: <cryptumount>/usr/local/sbin/unmountLuks %(MNTPT)</cryptumount> In this situation, the DB LUKS device is destroyed (by luksClose) on log off.
So what does cmtab contain?
Nothing. I does not exist: pavel@pbaranchikov:~/workspace/CMS/CMS> cat /etc/cmtab cat: /etc/cmtab: No such file or directory
The path is /var/run/cmtab.
pavel@pbaranchikov:/var/run> cat cmtab /home/pavel/containercontents /home/pavel/container.img /dev/loop2 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop1 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop2 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop4 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop0 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop6 /dev/mapper/_home_pavel_container_img
>/home/pavel # umount.crypt -f /home/pavel/containercontents >/home/pavel/containercontents is not mounted (according to cmtab) Please retry the mount.crypt - umount.crypt cycle with pam_mount v2.11 from /repositories/Linux-PAM where I have added extra diagnostics to help narrow down what is found. Use -v for verbose: # mount.crypt -v /home/pavel/container.img /home/pavel/containercontents # umount.crypt -v /home/pavel/containercontents
mount.crypt/umount.crypt seem to work well. But the /var/run/cmtab file contents left unchanged. pbaranchikov:/home/pavel # mount.crypt -v /home/pavel/container.img /home/pavel/containercontents BIG FAT WARNING: This version of mount.crypt does not support unmounting crypto volumes through umount(8) on systems with read-only mtab yet. Password: mount.crypt(mtcrypt.c:409): keysize=13 trunc_keysize=32 mount.crypt(crypto.c:67): Setting up loop device for file /home/pavel/container.img mount.crypt(crypto.c:78): Using /dev/loop0 mount.crypt(crypto-dmc.c:150): Using _home_pavel_container_img as dmdevice name command: 'mount' '/dev/mapper/_home_pavel_container_img' '/home/pavel/containercontents' pbaranchikov:/home/pavel # ls /dev/mapper control _home_pavel_container_img pbaranchikov:/home/pavel # umount.crypt -v /home/pavel/containercontents BIG FAT WARNING: This version of mount.crypt does not support unmounting crypto volumes through umount(8) on systems with read-only mtab yet. umount.crypt(mtcrypt.c:643): Found crypto device in smtab command: 'umount' '/home/pavel/containercontents' pbaranchikov:/home/pavel # ls /dev/mapper control pbaranchikov:/home/pavel # cat /var/run/cmtab /home/pavel/containercontents /home/pavel/container.img /dev/loop2 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop1 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop2 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop4 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop0 /dev/mapper/_home_pavel_container_img /home/pavel/containercontents /home/pavel/container.img /dev/loop6 /dev/mapper/_home_pavel_container_img
But pam_mount.so still do the error. The output is after logon/logout: pbaranchikov:/home/pavel/workspace/CMS/CMS/MA/src/main/webapp # ls /dev/mapper control _home_pavel_container_img pbaranchikov:/home/pavel/workspace/CMS/CMS/MA/src/main/webapp # ls /home/pavel | grep container container.img container.key
>mount.crypt/umount.crypt seem to work well. Good, then this is resolved. >But the /var/run/cmtab file contents left unchanged. Yeah; the file is now /run/cmtab in accordance with http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html . >But pam_mount.so still do the error. That would then be because pam_mount defaults to calling umount(8) rather than umount.crypt(8): rdconf1.c: {CMD_CRYPTUMOUNT, "crypt", {"umount", "%(MNTPT)", NULL}},] Use the following in pam_mount.conf.xml as a temporary workaround: <cryptumount>umount.crypt %(MNTPT)</cryptumount>
One little bug remains. Mount directory /home/pavel/containercontents is not removed on logout, despite of pam_mount.conf.xml: <mkmountpoint enable="1" remove="true" /> And a question: will the pam_mount 2.11 arrive in official openSuSE repositories?
>Mount directory /home/pavel/containercontents is not removed on logout If the directory existed previously (i.e. if pam_mount did not need to mkdir), it will not be removed either. Perhaps it is the remnant of one of the previous tries?
TBA
Requesting update slot & swamp id for an update to pam_mount.
can we take alook at the proposed package somewhere?
It's the current one in /Linux-PAM/pam_mount. (This requires an update to libHX too, cf. /devel:libraries:c_c++/libHX.)
Do other things depend on libHX? is the version update binary compatible for those?
Binary compatible no — it will move from libHX25 to libHX27, but the logical API is the same[1], so recompilation of hxtools is not expected to fail at all. (And I just verified that the checkout of hxtools-20110214 still compiles with libHX-3.11.) [1] http://libhx.git.sf.net/git/gitweb.cgi?p=libhx/libhx;a=commitdiff;h=5495aacc0
as no other packages depend on it, we could bump pam_mount and libHX I take it the binary package libHX25 will turn into libHX27? any others new or eremoved?
>any others new or removed? None.
The SWAMPID for this issue is 42683. This issue was rated as low. Please submit fixed packages until 2011-09-13. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/42683
+1, update started. Be so kind and submit the fixed sources. Rudi, be so kind and update the maintained data for 11.4. See comment #28: libHX25 -> libHX27
libHX25,libHX25-32bit,libHX25-debuginfo replaced
sr 79091 79092
This is an autogenerated message for OBS integration: This bug (671276) was mentioned in https://build.opensuse.org/request/show/79091 11.4 / libHX https://build.opensuse.org/request/show/79092 11.4 / pam_mount
added for maintenance
cgardner rejected: >The baselibs.conf doesn't look quite right. Dirk Mueller and I believe it >should look like this: >libHX27 >libHX-devel > requires -libHX > requires -libHX27 > requires "libHX27-<targettype> = <version>" I based this baselibs.conf upon what preexisted in openSUSE, e.g. openSUSE:11.4/util-linux. Since libHX-devel-32bit does not require libHX in the first place, there is no need to exclude it.
rejected by autobuild -> reopening
it looks fine now, dont see why it needs requires -libHX27 ?
it does not look fine. requiring libHX27 or not is not the main issue, but you have to block the (autogenerated) requires for libHX.
Dirk, be so kind and have a look to bring this update forward.
see comment #39
Not sure who is to respond now. Anyhow, building without any "requires" lines in baselibs.conf would give the following requires: ($ osc build ...) $ rpm -qRp /var/tmp/b-openSUSE_11.4-i586/usr/src/packages/RPMS/x86_64/libHX27-32bit-3.11-1.x86_64.rpm /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) rpmlib(PayloadIsLzma) <= 4.4.6-1 $ rpm -qRp /var/tmp/b-openSUSE_11.4-i586/usr/src/packages/RPMS/x86_64/libHX-devel-32bit-3.11-1.x86_64.rpm libHX-devel = 3.11 libHX-32bit = 3.11 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3.4) rpmlib(PayloadIsLzma) <= 4.4.6-1 Therefore, baselibs.conf has libHX-devel requires -libHX-<targettype> requires libHX27-<targettype> = <version> This follows the baselibs.conf entries that many other packages have. So I do not see where this is supposed to be wrong.
so it looks good here?
the built rpms look fine, checking in.
Update released for: libHX, libHX-debugsource, libHX-devel, libHX-devel-debuginfo, libHX25, libHX25-debuginfo, libHX27, libHX27-debuginfo, pam_mount, pam_mount-debuginfo, pam_mount-debugsource Products: openSUSE 11.4 (debug, i586, x86_64)
update released (new build)