Description of problem: I have pam_mounted encrypted home defined in /etc/security/pam_mount.conf.xml as <volume user="theuser" fstype="crypt" path="/dev/vg_libelle/lv_home_theuser_enc" mountpoint="/home/theuser" options="fstype=xfs" /> After I log out of my XFCE session and lightdm displays the logon prompt again, as a root I observe that /home/theuser was not unmounted. I believe it is because there are processes keeping the home directory busy. Version-Release number of selected component (if applicable): systemd-208-15.fc20.x86_64 pam_mount-2.14-1.fc20.x86_64 pulseaudio-4.0-9.gitf81e3.fc20.x86_64 gnupg2-2.0.22-1.fc20.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have pam_mounted home. 2. Log in to session, log out. 3. Check if home was unmounted. Actual results: Home still mounted, and the following processes still running: theuser 1310 0.0 0.0 44372 2352 ? Ss 17:04 0:00 /usr/lib/systemd/systemd --user theuser 1363 0.0 0.0 111568 5464 ? S 17:04 0:00 (sd-pam) theuser 1531 0.0 0.0 121284 444 ? Ss 17:04 0:00 /usr/bin/gpg-agent --sh --daemon --write-env-file /home/theuser/.cache/gpg-agent-info theuser 1623 0.1 0.0 551720 6320 ? S<l 17:04 0:00 /usr/bin/pulseaudio --start The pulseaudio ends after a couple more seconds but systemd, sd-pam, and gpg-agent are still there. Expected results: No processes, home unmounted. Additional info:
This appears a shortcoming in the design of pam_mount. It's totally common that user software stays running after logout, pulseaudio did that for a while, and so does systemd, until the last of the user's logout. Similar in style as screen or nohup stuff. Reassigning to pam_mount
pam_mount supports killing remaining programs when the last user session is logged out. See the <logout> tag in /etc/security/pam_mount.conf.xml, where you can specify a timeout and how to kill remaining programs. Therefore I guess there is not much that can be done. If you still see a bug, please leave a comment here or re-open the bug, if you can.
(In reply to Till Maas from comment #2) > pam_mount supports killing remaining programs when the last user session is > logged out. See the <logout> tag in > /etc/security/pam_mount.conf.xml, where you can specify a timeout and how to > kill remaining programs. Therefore I guess there is not much that can be > done. If you still see a bug, please leave a comment here or re-open the > bug, if you can. I've changed <!-- requires ofl from hxtools to be present --> <logout wait="0" hup="0" term="0" kill="0" /> to <!-- requires ofl from hxtools to be present --> <logout wait="20" hup="1" term="1" kill="1" /> I still see systemd --user, sd-pam, gpg-agent, and pulseaudio --start running after logout and waiting a couple of seconds, and the home mounted. Running # rpm -qf /bin/ofl hxtools-20130605-2.fc20.x86_64 shows that ofl from hxtools is installed. What is the way of reliably killing all user processes and unmounting the home directory?
Do you have selinux enabled? Are there any selinux denials?
see also bug:1161601
(In reply to Till Maas from comment #4) > Do you have selinux enabled? Are there any selinux denials? SELinux is enforcing. There are no AVC denials.
(In reply to Jan Pazdziora from comment #3) > <!-- requires ofl from hxtools to be present --> > <logout wait="20" hup="1" term="1" kill="1" /> According to the manpage wait is specified in microseconds. IIRC I in the config I saw the selinux bug "yes" instead of "1" was used and a 2000 or 20000 for wait (I assumed it was milliseconds then).
(In reply to Till Maas from comment #7) > (In reply to Jan Pazdziora from comment #3) > > > <!-- requires ofl from hxtools to be present --> > > <logout wait="20" hup="1" term="1" kill="1" /> > > According to the manpage wait is specified in microseconds. IIRC I in the > config I saw the selinux bug "yes" instead of "1" was used and a 2000 or > 20000 for wait (I assumed it was milliseconds then). Thanks for pointing it out. I've changed the line to <logout wait="20000" hup="yes" term="yes" kill="yes" /> but I still do not see any change in behaviour -- systemd --user, sd-pam, and gpg-agent are still left running and the home directory is mounted. I've tried it in Permissive as well to avoid hitting bug 1161601.
Created attachment 958477 [details] pam_mount config that triggers selinux denial Here is the config that I saw the selinux denial with. Do you see any differences to your config?
(In reply to Till Maas from comment #9) > Created attachment 958477 [details] > pam_mount config that triggers selinux denial > > Here is the config that I saw the selinux denial with. Do you see any > differences to your config? I took your config file, replaced FIXME's with my values. Put SELinux to permissive. Running ssh user@the-machine causes: type=AVC msg=audit(1416314687.254:426): avc: denied { getattr } for pid=1618 comm="sshd" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314687.254:427): avc: denied { read write } for pid=1618 comm="sshd" name="utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314687.254:427): avc: denied { open } for pid=1618 comm="sshd" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314689.453:429): avc: denied { getattr } for pid=1618 comm="sshd" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314689.453:430): avc: denied { read write } for pid=1618 comm="sshd" name="utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314689.453:430): avc: denied { open } for pid=1618 comm="sshd" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 During logout, no AVC denials are shown and /usr/lib/systemd/systemd --user and (sd-pam) and home is not unmounted. When logging in on a console, I see type=AVC msg=audit(1416314891.323:457): avc: denied { getattr } for pid=1843 comm="login" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314891.323:458): avc: denied { read write } for pid=1843 comm="login" name="utab" dev="tmpfs" ino=211 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416314891.323:458): avc: denied { open } for pid=1843 comm="login" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 and (mount.c:68): Messages from underlying mount program: (mount.c:72): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted. (mount.c:68): Messages from underlying mount program: (mount.c:72): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted. (mount.c:72): crypt_activate_by_passphrase: File exists (pam_mount.c:522): mount of /dev/the/path failed and home is mounted (I'm in permissive). After exit, no progress of that user is left running, no AVC denials is shown, and the home stays mounted. When logging in on lightdm (no gdm here), I get AVC denials type=AVC msg=audit(1416315163.224:497): avc: denied { getattr } for pid=1368 comm="lightdm" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416315163.224:498): avc: denied { read write } for pid=1368 comm="lightdm" name="utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416315163.224:498): avc: denied { open } for pid=1368 comm="lightdm" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416315163.258:499): avc: denied { getattr } for pid=1368 comm="lightdm" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416315163.258:500): avc: denied { read write } for pid=1368 comm="lightdm" name="utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1416315163.258:500): avc: denied { open } for pid=1368 comm="lightdm" path="/run/mount/utab" dev="tmpfs" ino=211 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=1 After logout, I see /usr/bin/ssh-agent, /usr/bin/gpg-agent, and /usr/bin/pulseaudio --start running (no systemd --user though this time) and the home is not unmounted. No new AVC denials are logged. In summary, I don't see AVC denials during logout / umount like bug 1161601 does but it might be because the umount is not even run in my case. This is with selinux-policy-targeted-3.12.1-193.fc20.noarch.
*** Bug 998129 has been marked as a duplicate of this bug. ***
In the end, on Fedora 21, I've "fixed" the issue by following http://docs.xfce.org/xfce/xfce4-session/advanced and running xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false to get rid of the gpg-agent process which seemed to cause the systemd --user to stay around, preventing the unmount.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.