* Paul Leiber <[email protected]> [2026-03-04 11:11]:
Hi Jochen,Thank you for looking into this. Long story short: The "fix" for bug 1034339 introduced the issue. Removing the line <pmvarrun>/usr/sbin/pmvarrun -u %(USER)</pmvarrun> from pam_mount.conf.xml solved this issue (and brought back the issue from bug 1034339 when exiting a "sudo -i" session). Am 03.03.26 um 15:57 schrieb Jochen Sprickerhof:control: tag -1 moreinfo control: severity -1 normal Hi Paul, * Paul Leiber <[email protected]> [2026-03-03 13:07]:On a workstation PC running Debian Trixie, I have configured pam-mount so that it mounts some samba shares with user data at login. That is working well for a single user. However, I noticed that after logging out as a specific user A and then logging in as another user B, the mounts from user A still exist (and vice versa). This is of course not acceptable for several reasons (e.g. privacy, security).This is not a privacy or security issue as other uses can log in at the same time to see the mounts. Thus downgrading severity.I agree.I found some ancient bug reports [1] where pam was not able to use root rights and therefore couldn't unmount the volumes. I am pretty sure that this is not the case here, as the bug was fixed long ago and I don't see this specific log entry on my system.Nit: reference missing.Sorry. https://bugs.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736I found several bugs in the Debian pam-mount package describing unmount not happening, but with other symptoms. In one of the reports, 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"/> solved a similar issue. I changed this config line, but without a noticable effect. What I noticed in the pam-mount logs while digging deeper was a line saying that "user A seems to have other remaining open sessions". I then checked the session tracker in /var/run/pam_mount/, and the numbers there don't seem to be correct. After the first login of user A to a desktop, the value stored in "/var/run/pam_mount/user A" is 0x1. After logging out, it is 0x2. With each new login, the number is increased by 1 after login and by 1 after logout. With the help from Debian user mailing list, I executed strace -f -s 10000 -e execve -p $(pidof login | tr ' ' ,) -o /tmp/strace_login before login and logout. It gives the following output:For reference: https://lists.debian.org/debian-user/2026/03/msg00015.htmlFor login: 9414 execve("/usr/sbin/pmvarrun", ["/usr/sbin/pmvarrun", "-u", "xxx"], 0x55ec223822c0 /* 11 vars */) = 0 For logout: 9483 execve("/usr/sbin/pmvarrun", ["/usr/sbin/pmvarrun", "-u", "xxx"], 0x55ec223822c0 /* 17 vars */) = 0 The results indicate that instead of decreasing the count at logout using arguments '-o' '-1', the count is increased by the default value. Thus, the session counter never reaches 0 and this prevents unmount.I can't reproduce this. What I tried: debvm-create -k ~/.ssh/id_ed25519.pub -r trixie -- \ --hook-dir=/usr/share/mmdebstrap/hooks/useradd \ --include=libpam-mount,libpam-mount-bin \ --customize-hook='truncate -s100M $1/image.img; mkfs.ext4 $1/image.img; sed -i \'$ i <volume path="/image.img" mountpoint="/mnt" user="user" />\' $1/etc/security/pam_mount.conf.xml' debvm-run -s 2222 In a new terminal: ssh -p 2222 user@localhost sleep 5 In the debvm-run terminal: Debian GNU/Linux 13 testvm ttyS0 testvm login: root (automatic login) pam_mount password:[ 2.667557] RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer [ 2.690571] cryptd: max_cpu_qlen set to 1000 [ 2.754126] AES CTR mode by8 optimization enabled Linux testvm 6.12.73+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@testvm:~# [ 6.399162] loop: module loaded [ 6.400183] loop0: detected capacity change from 0 to 204800 [ 6.405868] EXT4-fs (loop0): mounted filesystem 622fd4f2-5408-4187-907c-a7244c13fd25 r/w with ordered data mode. Quota mode: none. root@testvm:~# awk 1 /run/pam_mount/user # while the user is logged in 0x1 root@testvm:~# [ 14.870179] EXT4-fs (loop0): unmounting filesystem 622fd4f2-5408-4187-907c-a7244c13fd25. root@testvm:~# awk 1 /run/pam_mount/user # after the logout awk: cannot open "/run/pam_mount/user" (No such file or directory) Also from the source code it is pretty clear that pmvarrun is run with -o -1. Can you please provide a reproducer?I can confirm that on a fresh Debian Trixie VM joined as a Samba domain member and with a minimal pam_mount.conf.xml to mount a Samba share, pmvarrun is run with the correct arguments: On login: command: 'pmvarrun' '-u' 'xxx' '-o' '1' On logout: command: 'pmvarrun' '-u' 'xxx' '-o' '-1' Also, there is no file for the user in /var/run/pam_mount after logout, and unmount is executed at logout. Looking at the logs and the strace output, I assumed that the cause of the unmount not happening is indeed that arguments "-o 1" and "-o -1" for pmvarrun are dropped. What I then tried to find the cause: 1. To create a system similar to the workstation PC, I added missing pam packages libpam-krb5 and libpam-systemd in the VM, with no effect on the pmvarrun arguments. 2. I ran pam-auth-update on the workstation PC to restore configuration files in pam.d, but the issue still existed. 3. I checked the versions of libpam-mount on both the workstation PC and the VM, they are identical (2.20-3+b2). 4. I compared the pam_mount.conf.xml files. One difference seemed potentially relevant: On the workstation PC, there is the line <pmvarrun>/usr/sbin/pmvarrun -u %(USER)</pmvarrun> which I added to solve an issue described in bug 1034339 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034339. Success! Removing that line resolved the issue of unmount not happening. However, it reintroduced the issue from bug 1034339 (output "HXproc_run_async: pmvarrun: No such file or directory" when exiting a "sudo -i" session). After some testing, it seems that this is not a bug and therefore can be closed.
Done.
However, there are two follow-ups: 1. Should bug 1129584 (this bug) be referenced in the bug report for bug 1034339 to avoid other users running into this issue?
Cced.
2. What could a better fix for bug 1034339 (this will probably make more sense to discuss in the thread for bug 1034339)?
I wonder if it would help to move pmvarrun to /usr/bin, can you try? Cheers Jochen
signature.asc
Description: PGP signature
