Description of problem: If I setup ecryptfs for my user (doing `sudo authselect select sssd with-ecryptfs with-pamaccess` in the process), I can no longer use systemd user services. `systemctl --user` does not see the services (in ~/.config/systemd/user) as existing at all until a `systemctl --user daemon-reload` is performed after login. Presumably this is due to the directory not being decrypted at the time that systemd is looking for them on login, much as in this issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1746527 Version-Release number of selected component (if applicable): pam-1.3.1-17.fc30 How reproducible: 100% Steps to Reproduce: 1. Setup ecryptfs (ecryptfs-migrate-home and the above authselect command among it) 2. Create a systemd user service and enable it 3. Reboot and try to do a `systemctl --user status <service>` Actual results: Service is missing Expected results: Service should be usable Additional info:
Can you copy and paste /etc/pam.d/system-auth and /etc/pam.d/postlogin please?
/etc/pam.d/system-auth # Generated by authselect on Fri Sep 6 01:08:01 2019 # Do not modify this file manually. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_access.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_ecryptfs.so unwrap -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so /etc/pam.d/postlogin # Generated by authselect on Fri Sep 6 01:08:01 2019 # Do not modify this file manually. auth optional pam_ecryptfs.so unwrap password optional pam_ecryptfs.so unwrap session optional pam_umask.so silent session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed Hm, seems like pam_ecryptfs.so unwrap *does* occur bfore
So pam_ecryptfs is called before pam_systemd in session phase which is correct. Even the issue mentioned in the bug description advice this order as a fix. I'm moving this bug to systemd for further investigation.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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 Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.