Bug 671276

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)