Bugzilla – Bug 1038454
encrypted home directory is not unmounted when user logs out
Last modified: 2018-04-17 14:09:33 UTC
On a multi-user system I created several user accounts with encrypted home directories by using the "User and Group Management" module in YaST. When user A (with encrypted home) logs out and user B with root access logs in, it is possible for user B to access the files in the home directory of user A. This is not supposed to happen. I also tried encrypting the home directories using eCryptfs and the problem persists. Therefore I assume it's not a YaST related bug. Steps to reproduce: 1) create a new user using YaST, encrypt the home directory 2) login as new user, create a text file 3) logout and login as root 4) try to access home directory of new user (which should be encrypted but is not) I've also attached a video. Expected behaviour: Root can't access files in other users encrypted home directory.
Created attachment 724517 [details] videofile reproducing the bug
This might be a duplicate of bug 1033206
(In reply to Matthias Gerstner from comment #2) > This might be a duplicate of bug 1033206 The effect seems to be the same but I'm not sure whether the cause is. I'm pretty sure YaST does not use Ecryptfs. Also the workaround you've posted (https://bugzilla.suse.com/show_bug.cgi?id=1033206#c2) does not work for me.
(In reply to cfd_s12@web.de from comment #3) > I'm pretty sure YaST does not use Ecryptfs. You're right. YaST uses cryptconfig, LUKS based encrypted files, which are loop-mounted via pam_mount into the home directory. So if your home is not unmounted during logout then the problem probably is in the area of pam_mount. You are using Leap 42.2, right? I tried to reproduce this on a test installation but was not successful. So there must be some additional influence in your setup. pam_mount keeps a session counter in /var/run/pam_mount/<user>. Only when this counter reaches zero, the unmount will be performed. You can check out this value before login, while logged in an after being logged out. You can also check the output of `journalctl -f` as root, while doing login/logout. Maybe some warning or error message related to pam_mount can be seen. Also check whether your /etc/pam.d/xdm file contains this line: session optional pam_mount.so Maybe you can attach this file to the bug, just in case some other session modules influence your installation. You can also check whether the unmounting works if done on a login text console instead of the graphical login, because in this case a different PAM configuration applies. Thank you.
(In reply to Matthias Gerstner from comment #4) > (In reply to cfd_s12@web.de from comment #3) > > > I'm pretty sure YaST does not use Ecryptfs. > > You're right. YaST uses cryptconfig, LUKS based encrypted files, which are > loop-mounted via pam_mount into the home directory. > > So if your home is not unmounted during logout then the problem probably is > in > the area of pam_mount. You are using Leap 42.2, right? I tried to reproduce > this on a test installation but was not successful. So there must be some > additional influence in your setup. > > pam_mount keeps a session counter in /var/run/pam_mount/<user>. Only when > this > counter reaches zero, the unmount will be performed. > > You can check out this value before login, while logged in an after being > logged out. You can also check the output of `journalctl -f` as root, while > doing login/logout. Maybe some warning or error message related to pam_mount > can be seen. > > Also check whether your /etc/pam.d/xdm file contains this line: > > session optional pam_mount.so > > Maybe you can attach this file to the bug, just in case some other session > modules influence your installation. > > You can also check whether the unmounting works if done on a login text > console instead of the graphical login, because in this case a different PAM > configuration applies. > > Thank you. Thanks for your quick reply, I will test, log and respond again. So far a got a quick update. I'm using openSUSE Leap 42.2 with Plasma 5. I tried to reproduce the bug with an unpatched openSUSE Leap 42.2 GNOME as well as with the current SLED 12 SP3 beta2. In both cases the behavior could NOT be reproduced, so maybe it's a Plasma 5 or sddm related thing? When I saw your line about editing /etc/pam.d/xdm, I remembered that there was a Plasma related bug that prevented accessing encrypted home directories. A workaround was to login in tty first and after that login using the display manager (not sure if kdm or sddm) or to add some lines in /etc/pam.d/??? very similar to yours. Sounds like this could be related. I will do some research and respond back. Thank you very much so far!
Thanks to Thomas Rother and David Kerkhof. The problem is fixed when using the following configuration is used: > > duda@linux:~> cat /etc/pam.d/sddm > > #%PAM-1.0 > > auth optional pam_mount.so > > auth include common-auth > > account include common-account > > password include common-password > > session required pam_loginuid.so > > session include common-session > > session optional pam_cryptpass.so > > session optional pam_mount.so This should be used in Leap 42.3! Got the solution from Bug 954419
(In reply to P. Otato from comment #6) > Thanks to Thomas Rother and David Kerkhof. The problem is fixed when using > the following configuration is used: > > > > duda@linux:~> cat /etc/pam.d/sddm > > > #%PAM-1.0 > > > auth optional pam_mount.so > > > auth include common-auth > > > account include common-account > > > password include common-password > > > session required pam_loginuid.so > > > session include common-session > > > session optional pam_cryptpass.so > > > session optional pam_mount.so > > This should be used in Leap 42.3! Got the solution from Bug 954419 The question remains as to whether this should be added to sddm only or should be put into common-auth and common-session! As it stands, this will only solve the issue when logging in through sddm, but not if eg the user logs in through ssh. My suggestion in Bug 954419 was to put the line auth optional pam_mount.so into common-auth and the lines session optional pam_cryptpass.so session optional pam_mount.so so they are available to all aplications, not just sddm.
The last two lines should be put into common-session!
(In reply to Josef Möllers from comment #9) > The question remains as to whether this should be added to sddm only or > should be put into common-auth and common-session! > As it stands, this will only solve the issue when logging in through sddm, > but not if eg the user logs in through ssh. > > My suggestion in Bug 954419 was to put the line > auth optional pam_mount.so > into common-auth and the lines > session optional pam_cryptpass.so > session optional pam_mount.so > so they are available to all aplications, not just sddm. (In reply to Josef Möllers from comment #8) > The last two lines should be put into common-session! I tried your suggested solution and I am able to login but the encrypted home directory is not unmounted after logout. /etc/pam.d/sddm > #%PAM-1.0 > auth include common-auth > account include common-account > password include common-password > session required pam_loginuid.so > session include common-session /etc/pam.d/common-auth > #%PAM-1.0 > # > # This file is autogenerated by pam-config. All changes > # will be overwritten. > # > # Authentication-related modules common to all services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of the authentication modules that define > # the central authentication scheme for use on the system > # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the > # traditional Unix authentication mechanisms. > # > auth optional pam_mount.so > auth required pam_env.so > auth optional pam_gnome_keyring.so > auth required pam_unix.so try_first_pass /etc/pam.d/common-session > #%PAM-1.0 > # > # This file is autogenerated by pam-config. All changes > # will be overwritten. > # > # Session-related modules common to all services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of modules that define tasks to be performed > # at the start and end of sessions of *any* kind (both interactive and > # non-interactive > # > session required pam_limits.so > session required pam_unix.so try_first_pass > session optional pam_umask.so > session optional pam_systemd.so > session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm > session optional pam_env.so > session optional pam_cryptpass.so > session optional pam_mount.so
(In reply to P. Otato from comment #9) > (In reply to Josef Möllers from comment #9) > > The question remains as to whether this should be added to sddm only or > > should be put into common-auth and common-session! > > As it stands, this will only solve the issue when logging in through sddm, > > but not if eg the user logs in through ssh. > > > > My suggestion in Bug 954419 was to put the line > > auth optional pam_mount.so > > into common-auth and the lines > > session optional pam_cryptpass.so > > session optional pam_mount.so > > so they are available to all aplications, not just sddm. > > (In reply to Josef Möllers from comment #8) > > The last two lines should be put into common-session! > > I tried your suggested solution and I am able to login but the encrypted > home directory is not unmounted after logout. I just set up my Leap42.3 VM to mount an unencrypted data directory into my user's HOME directory and it was mounted when I first logged in and umounted when I last logged out again. I have "<mkmountpoint enable="1" remove="true" /> in /etc/security/pam_mount.conf.xml and my ~/.pam_mount.conf.xml has, effectively, only this one line: <volume options="nodev,nosuid" user="*" mountpoint="/home/josef/MPGs" path="/mnt/Videos" server="firefly" fstype="nfs" /> Can you 1) enable debug in /etc/security/pam_mount.conf.xml: -<debug enable="0" /> +<debug enable="1" /> 2) completely log out of the system 3) Log-in as "root" (or some other user) 4) "su - <testuser>" and immediately log out again Step 4 should give you some (understatement of the month) debug output. Please post the output here.
This is automated batch bugzilla cleanup. The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such it 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 openSUSE, or you can still observe it under openSUSE Leap 15.0, please feel free to reopen this bug against that version (see the "Version" component in the bug fields), or alternatively open a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime