Description of problem & possible fix:

While there are lots of issues with full user home directory encryption in Fedora, this one is fairly straightforward to fix.

In `/etc/pam.d/sddm` there are currently these lines (among others):

    …
    session     required      pam_namespace.so
    session     include       password-auth
    -session     optional      pam_gnome_keyring.so auto_start
    -session     optional      pam_kwallet5.so
    -session     optional      pam_kwallet.so
    session     include       postlogin

While this may seem sensible, it breaks down in case of the pam_ecryptfs.so module which is part of `/etc/pam.d/postlogin`; by the time `pam_ecryptfs.so` does it's overlay mounting thing, gnome keyring & kwallet have long given up on looking for their respective files and the respective password stores will remain locked.

The solution is therefore to simply make unlocking password stores the very last thing to happen upon session initialization:

    …
    session     required      pam_namespace.so
    session     include       password-auth
    session     include       postlogin
    -session     optional      pam_gnome_keyring.so auto_start
    -session     optional      pam_kwallet5.so
    -session     optional      pam_kwallet.so

Then it works as expected 😀



Version-Release number of selected component (if applicable): 0.14.0


How reproducible: Always


Steps to Reproduce:
1. Set SELinux to permissive mode (told there are lot of issues with `ecryptfs` on Fedora currently) and reboot
2. Create a new user account and log in and open `seahorse` / `kwalletmanager5` to create the respective password storage, then log out again
3. From a virtual console run `ecryptfs-migrate-home --user $USER` as root
4. Also add the user to the `ecryptfs` group
5. After the migration completes log in and open `seahorse` or `kwalletmanager5`


Expected results:

No password prompt, log in password is used to decrypt the password store.


Actual results:

A password prompt, errors in `journalctl`.