I've made some progress on this bug, so I'm forwarding my bug report to debian to this to document it here, too. -j -------- Original Message -------- Subject: libpam-mount: pam mounted home directories not unmounted on logout (and mounted twice) Date: Mon, 02 Apr 2012 10:18:48 +0200 From: josh <jbuhl_nospam@xxxxxxx> To: debian bugs <submit@xxxxxxxxxxxxxxx> CC: Debian Security Team <team@xxxxxxxxxxxxxxxxxxx> Package: libpam-mount Version: 2.14~git+d1d6f871-1 Severity: important Tags: security I have individually LUKS encrypted home dirs on my system which are mounted at login via pammount, which however do not get sucessfully unmounted on logout, leaving them readable for anybody else who logs in afterwards and has sufficient permissions (which at least partially defeats the purpose of having pam mounted encrypted home dirs.) Often, when partions don't get pam unmounted on logout it is because of processes (especially pulse audio) which aren't terminating, leaving open file handles, which prevent the partion from being unmounted. However, changing the "logout"-line in /etc/security/pam_mount.conf.xml from: <logout wait="0" hup="0" term="0" kill="0" /> to: <logout wait="2000" hup="0" term="1" kill="1"/> ensures that all processes are terminated, so this isn't the cause. Turning on pam mount debugging in pam_mount.conf.xml (<debug enable="2"/>) produces the following output when exiting: josh@howlingfantods:~$ exit exit (pam_mount.c:692): received order to close things (misc.c:39): Session close: (ruid/rgid=1000/1000, e=1000/1000) command: 'pmvarrun' '-u' 'josh' '-o' '-1' (misc.c:39): set_myuid<pre>: (ruid/rgid=1000/1000, e=1000/1000) (spawn.c:129): error setting uid to 0 (pam_mount.c:441): pmvarrun says login count is 0 command: 'pmt-ofl' '-k15' '/home/josh' command: 'pmt-ofl' '-k9' '/home/josh' (mount.c:873): going to unmount (mount.c:267): Mount info: globalconf, user=josh <volume fstype="crypt" server="(null)" path="/dev/disk/by-uuid/967e7b41-b9cc-48f0-94e8-c2c3eb2a4dd0" mountpoint="/home/josh" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="" /> fstab=0 ssh=0 command: 'pmt-ofl' '-k0' '/home/josh' command: 'umount.crypt' '/home/josh' (misc.c:39): set_myuid<pre>: (ruid/rgid=1000/1000, e=1000/1000) (spawn.c:129): error setting uid to 0 (mount.c:72): umount messages: (mount.c:76): umount: it seems /home/josh is mounted multiple times (mount.c:76): umount /home/josh failed with run_sync status 3 (mount.c:876): unmount of /dev/disk/by-uuid/967e7b41-b9cc-48f0-94e8-c2c3eb2a4dd0 failed (pam_mount.c:729): pam_mount execution complete (pam_mount.c:133): clean system authtok=0x8bd9748 (0) (pam_mount.c:116): Clean global config (0) I have contacted upstream (Jan Engelhardt, the maintainer of libpam-mount), and he says that the problem is the "error setting uid to 0", which he says is usually a /distribution/ problem (hence the bug-report to debian), due to the authentication dropping it's privileges too early: On 04/01/2012 05:13 PM, Jan Engelhardt wrote: > I suppose that because uid!=0, umount tries to do something overly > smart rather than just go and umount the topmost dir as it always > did. > > The program doing the authentication must not drop its privileges. > In your case it does, which usually hints at a distribution bug. > This is your root problem, and described in docs/bugs.txt. > After logging out, the only way to get the decrypted partion unmounted is for root to do this by hand. I see this as a security risk because users encrypting their home partions rely on their data not being readable after they've logged out. Although confusing to me, upstream indicated that the fact that the home dir is mounted multiple times (see double mount below), is a /Feature-Not-A-Bug/ (c) and apparently not part of the problem. However, libpam-mount deletes the entry in /run/cmtab, even though the decrypted mapped device is still mounted, which causes umount.crypt to fail if called by hand to unmount the volume after logout. To unmount by hand, you have to unmount the fs and then unmap the device with cryptsetup luksClose device. This seems like an upstream bug in libpam-mount to me. -j **************************double mount******************************** I'm adding this section (and added it to the subject) to document this behaviour and the fact that upstream claims it's a /Feature-Not-A-Bug/(c),because I long believed this to be a bug and part of the problem, and in case anybody else searches for it. On 04/01/2012 05:13 PM, Jan Engelhardt wrote: > I suppose that because uid!=0, umount tries to do something overly > smart rather than just go and umount the topmost dir as it always > did. > > The program doing the authentication must not drop its privileges. > In your case it does, which usually hints at a distribution bug. > This is your root problem, and described in docs/bugs.txt. > pam-mount mounts the encrypted volumes twice, once as a decrypted dev mapped device and then as an fs (this seems strange to me, and I don't see the necessity, but upstream indicated that this is the correct behaviour.), and after mounting there are two entries in mtab: josh@howlingfantods:~$ df Filesystem 1K-blocks Used Available Use% Mounted on [irrelevant lines removed] /dev/mapper/_dev_sda1 57690744 20807472 36297152 37% /home/josh /dev/sda1 57690744 20807472 36297152 37% /home/josh josh@howlingfantods:~$ cat /etc/mtab [irrelevant lines removed] /dev/mapper/_dev_sda1 /home/josh ext4 rw 0 0 /dev/sda1 /home/josh crypt rw 0 0 josh@howlingfantods:~$ cat /run/cmtab /home/josh /dev/sda1 - /dev/mapper/_dev_sda1 After logout, only the fs gets unmounted, but the decrypted mapped device remains mounted. df reports after logout: /dev/mapper/_dev_sda1 57690744 20835284 36269340 37% /home/josh The entry in /run/cmtab gets removed, however, so unmount.crypt fails and you must do a regular unmount on /home/josh and then a cryptsetup luksClose to de-map the decrypted partion. -j _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
