Bug 954419

Can you please attach full yast logs?
https://en.opensuse.org/openSUSE:Report_a_YaST_bug

Created attachment 655506 [details]
YAST logs

I did some more checking and mounted the creates <user>.img to the user's home folder, and everything seems normal, all files are there. So I think it's not a YAST problem to create the encrypted home, but rather in the mounting part when logging in.

Yes, creation of the volumes look sane. Maybe pam_mount is not correctly configured? I'll check in my test system

I tested it and login works perfectly in text mode (tty). But logging into KDE I can reproduce the issue.

Reassigning to KDE maintainers, since it looks like a display manager issue to me.

David, can you confirm that it works for you as well in text mode (ctrl+alt+f1)?

Ok, I did as you mentioned, tty login, and it worked, I could see the files. I then tried to log in by going back ctrl+alt+f7 and entered the password again for the same user in the greeter and I was in KDE!

Logging in directly still doesn't work, I tried hoping it would have fixed the issue.

Try to replace sddm login with the kdm one as workaround. Seems sddm does not init something. Might be good candidate for openQA.

Before I did the fresh install I upgraded 13.2 to leap, and the encrypted home kept working with sddm log in, although I can't say if it was that or kdm was still there and started the whole thing. But because of lot's of instability issues and stuff not working and mixed kde4 kde5 stuff I decided to do a fresh install and it stopped working. I installed KDM but it doesn't appear in the greeter, but none of the methods, icewm or failsafe, work. Only thing that worked so far is log in in text mode on tty1 and then switch to tty7 and do the normal log in.
But I prefer to search for the real fix, not the KDM one because this will give more problems in the end and is not a long term solution. Meanwhile I have a working system, 13.2, on another partition and until it gets fixed I will keep working with that one

I have done some more troubleshooting, loading the required kernel modules doesn't fix it. It must be a pam thing, I will keep looking further.

As there are more ways how to create home encrypted partition could you please describe in installer how you achieved it? (for the openQA test so QA developer does not have to test for all variations :)).

You can add the description to: https://progress.opensuse.org/issues/9536

I accessed the link to openQA but see no way to write any comment.

To create the encrypted home, I just opened YAST, User and Group management, selected the user, Edit, and select to encrypt home, give a size, password is asked, and that's all.
One thing that never happens is that the user's files are moved. They are copied but remain in the home folder.

This morning I added a comment but it is gone, so here again.

I fixed the problem by changing /etc/pa.d/sddm to

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

The first line and last two lines were added, and since then I was able to log in. 

What still is an issue is that the encrypted home is not properly dismounted after log out, which could result in corrupted files, as I discovered in earlier opensuse versions.

Copied your comment there.

> I fixed the problem by changing /etc/pa.d/sddm to
> 
> 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
> 
> The first line and last two lines were added, and since then I was able to
> log in. 
> 
> What still is an issue is that the encrypted home is not properly dismounted
> after log out, which could result in corrupted files, as I discovered in
> earlier opensuse versions.

I can confirm that adding those fix loging using sddm. Also I can confirm that it keep secure home mounted after logout.

After using this setup for some months om leap, I haven't seen file corruption so the volume not being unmounted is not such a big deal, and I even take advantage of it so I can do some cleanup using systemd at shut down. It is only a problem when loggin out and then logging in again.

Copy from progress issue (See URL field):

Also I tried it with tumbleweed:
* I created a user 'tux'
* I changed its home to encrypted using yast
* I rebooted
* I cannot login using gdm (It asks me for 2 passwords: pam and keyfile and then behaves as described in bnc#954419)
* I can login to tty but I seem to get the old unencrypted version of the home directory (with the files I created before setting the home to encrypted). Also I get error messages (see attached log).


@Josef: Maybe it is more of a pam setup issue beneath the gdm/sddm or the gdm/sddm should be somehow adjusted. Could you please check it up and throw back if needed?

As David Kerkhof writes in comment #10, you need to explicitly add pam_mount to /etc/pam.d/sddm:
pam-config --service sddm -a --mount

Once that's included, it works, so it's not a PAM issue. I'd try for YaST which should add pam_mount to the relevant /etc/pam.d entries.
As an alternative, one could require sddm to always include pam_mount in /etc/pam.d/sddm. It does not hurt if it's there and you have nothing special to set up, after all, it was there in /etc/pam.d/{login,sudo,xdm}.

Reassigning back.

The problem is that it is not happening only on KDE but on gnome/GDM too.
So both pam services should be simply adjusted then I suppose.

I suppose since we do not install pam_mount in default install it needs to be either adjusted by yast installer, or even better done in pam-mount package post phase so it gets fixed even if user decides to add the encrypted home later on?

Yes, but what if, after installation of pam_mount, the administrator later decides to install sddm or gdm? Then pam_mount's post phase has already happened and nothing will be added.
BTW I do not see any pam-config stuff in pam_mount's post code.
I'm not that familiar with YaST.

in yast it is done in samba-client which is called by users: https://github.com/yast/yast-samba-client/blob/master/src/modules/Samba.rb#L912

in general, where it have to be done is package post-installation. Because yast have same problem. If in future administrator call zypper in, yast have no chance.
So my suggestion is to add to post-install of e.g. sddm macro like

%post
pam-config --service sddm -a --mount

Basically the question is if something would break if we would have the pam_mount in there even if the package is not present.

If it works we could alter it by default to contain those directives.

Otherwise we need some config list in /etc/sysconfig or somewhere similar and macros to run on each pam using package...

Since "pam_mount.so" is "optional", it does not matter if the module is present or not (unless it's the only module in the stack, but since there are always other modules in the "auth" and "session" stack, this should be OK.)

*** Bug 981013 has been marked as a duplicate of this bug. ***

*** Bug 983734 has been marked as a duplicate of this bug. ***

Confirming solution of David Kerkhof for leap 42.2: the configuration at /etc/pam.d/sddm needs to be modified. pam_mount.so is already included in the session, but we also need pam_cryptpass.so here. See original comment #c10 from David Kerkhoff:

----
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 can be closed at least for leap 42.2, but the config change should be included for 42.3 and following.

Reopening and assigning to gnome to fix gdm pam files too.

The problem still persists for sddm in Leap 42.1, 42.2 and 42.3 alpha. But I've had no problem with gdm in Leap 42.3 alpha.

*** Bug 1045704 has been marked as a duplicate of this bug. ***

*** Bug 1047257 has been marked as a duplicate of this bug. ***

The problem persists in Leap 42.3 build 300, it seems the config has not been modified. Therefore an affected user needs to find this bug report to get a proper solution. I would not call this an ideal solution.

Besides the current fix may be loosely associated with https://bugzilla.opensuse.org/show_bug.cgi?id=1038454

I confirm persistence of this issue in build 300 - I got here by submitting duplicate bug report to this earlier.

Would it be possible - for someone who understands the problem and the workaround - to document step by step what needs to be done by user and put it to 42.3 release notes - PLEASE?

Given, that this is almost 2 years old - it seems to be one of these things which are here to stay - I am personally not able to understand the tread properly or contribute a fix beyond reporting and testing.

Thank you, Tomas

Additional data:
When logging in using ssh as a user with encrypted /home dir - the encrypted overlay image is not mounted - user has no access to encrypted data.

It seems that the bug is not isolated just to  sddm/kdm/gdm it is basic login infrastructure problem.

Hope it helps, Tomas

As David has mentioned in comment #10, two instances of pam_mount.so, and  Thomas has added in comment #23 one instance of pam_cryptpass.so need to be added.

On a Leap 42.3 machine, I have added
* "auth optional pam_mount.so" at the start of "common-auth" and
"session optional pam_cryptpass.so" and "session optional pam_mount.so" at the end of "common-session"

As we seem to have a pretty wide audience here, can you please try this too?
I have found that, other than some messages in the journal, this does not seem to have any adverse effects, because both modules are marked "optional". But then, I've only tried logging in and out of the system, and running at and cron jobs.

*** Bug 1047261 has been marked as a duplicate of this bug. ***

Thank you for the summary description Josef - I will try that tomorrow on my side and report back.

The fix in /etc/pam.d/sddm solves logging into KDE.

This has no effect on loging in by SSH. When I login remotely the encrypted home is still not mounted.

Could you please advise me if I should open separate bug report for ssh login?

Thanks to Thomas Rother and David Kerkhof, your additions helped fixing Bug 1038454
I strongly suggest that the updated configuration should be integrated in Leap 42.3

(In reply to Tomas Kuchta from comment #35)
> Could you please advise me if I should open separate bug report for ssh
> login?
I'm experiencing the same problem and I think a new bug report would be good. The initial problem (unable to login) is solved. If you open a new report, please link it here.

(In reply to Tomas Kuchta from comment #34)
> The fix in /etc/pam.d/sddm solves logging into KDE.
> 
> This has no effect on loging in by SSH. When I login remotely the encrypted
> home is still not mounted.

The problem seems to be that with ssh(d), session setup is done as root but session cleanup is done as the (unprivileged) user.
Root mounts the file system but the user cannot umount.

So, I second that a bug against openssh should be opened.

This is automated batch bugzilla cleanup.

The openSUSE 42.3 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 (At this moment openSUSE Leap 15.1, 15.0 and Tumbleweed) please
feel free to reopen this bug against that version (!you must update the
"Version" component in the bug fields, do not just reopen please), or
alternatively create 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