This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1467734 - Gnome Keyring/KWallet not unlocked when using ecryptfs full home directory encryption
Gnome Keyring/KWallet not unlocked when using ecryptfs full home directory en...
Status: NEW
Product: Fedora
Classification: Fedora
Component: sddm (Show other bugs)
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Bříza
Fedora Extras Quality Assurance
Depends On:
Blocks: 1477067
  Show dependency treegraph
Reported: 2017-07-04 19:05 EDT by alexander-rh
Modified: 2017-08-03 11:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description alexander-rh 2017-07-04 19:05:05 EDT
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
    session     include       password-auth
    -session     optional auto_start
    -session     optional
    -session     optional
    session     include       postlogin

While this may seem sensible, it breaks down in case of the module which is part of `/etc/pam.d/postlogin`; by the time `` 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
    session     include       password-auth
    session     include       postlogin
    -session     optional auto_start
    -session     optional
    -session     optional

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`.
Comment 1 Rex Dieter 2017-07-05 14:47:26 EDT
Thanks for the excellent detective-work
Comment 2 alexander-rh 2017-07-09 12:17:32 EDT
Unfortunately the solution I posted doesn't always seem work (and I'm not sure why, yet).
I'll add a new comment once I've figured out when and why it fails at time.

Note You need to log in before you can comment on or make changes to this bug.