Bug 1038454

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