systemd 239 in RHEL 8 beta (and Fedora?) automatically attempts to start user session whenever user logs in. This results in running PAM session validation for systemd-user PAM service as part of PAM session setup. Below is one example where IPA admin user tries to login over ssh with GSSAPI and fails:
Jan 10 04:12:31 kvm-01-guest10 sshd[1727]: Authorized to admin, krb5 principal admin@JANHB1.TEST (ssh_gssapi_krb5_cmdok) Jan 10 04:12:37 kvm-01-guest10 sshd[1727]: Accepted gssapi-with-mic for admin from 10.8.1.11 port 57802 ssh2: admin@JANHB1.TEST Jan 10 04:12:37 kvm-01-guest10 systemd[1737]: pam_sss(systemd-user:account): Access denied for user admin: 6 (Permission denied) Jan 10 04:12:37 kvm-01-guest10 sshd[1727]: pam_systemd(sshd:session): Failed to create session: Start job for unit user@77200000.service failed with 'failed' Jan 10 04:12:37 kvm-01-guest10 sshd[1727]: pam_unix(sshd:session): session opened for user admin by (uid=0) Jan 10 04:12:37 kvm-01-guest10 sshd[1727]: error: PAM: pam_open_session(): System error
As you can see, pam_sss(systemd-user:account) fails due to SSSD running HBAC access check in account phase and systemd-user is not being in the list of allowed services.
We need to add systemd-user HBAC service to the set of default services. I think we also need to create an HBAC group that includes services that are causing systemd-user PAM service use. At least, sshd and login?
I verified that adding such HBAC services indeed fixes the login.
Metadata Update from @abbra: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1664974
Metadata Update from @abbra: - Issue set to the milestone: FreeIPA 4.7.3
Metadata Update from @cheimes: - Issue assigned to cheimes
The new rule from https://github.com/freeipa/freeipa/pull/2746 fixes the issue
# journalctl -u user@487600001.service -o cat ... Starting User Manager for UID 487600001... pam_sss(systemd-user:account): Access denied for user testuser1: 6 (Permission denied) PAM failed: Permission denied user@487600001.service: Failed to set up PAM session: Operation not permitted user@487600001.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted user@487600001.service: Failed with result 'protocol'. Failed to start User Manager for UID 487600001.
Starting User Manager for UID 487600001... pam_unix(systemd-user:session): session opened for user testuser1 by (uid=0) Starting D-Bus User Message Bus Socket. Reached target Paths. Started Mark boot as successful after the user session has run 2 minutes. Reached target Timers. Listening on D-Bus User Message Bus Socket. Reached target Sockets. Reached target Basic System. Reached target Default. Startup finished in 78ms. Started User Manager for UID 487600001.
Metadata Update from @cheimes: - Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/2746 - Issue priority set to: critical - Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.7.3)
master:
ipa-4-7:
ipa-4-6:
Metadata Update from @cheimes: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
@simo suggested to remove the HBAC rule again and instead have SSSD allow the service by default. He argued that there is no technical reason to make the systemd-user service configurable. It has to be enabled always to make logins work.
The approach would also solve the case of new clients and old IPA servers without the rule.
Metadata Update from @cheimes: - Custom field affects_doc adjusted to on - Issue status updated to: Open (was: Closed)
@jhrozek what do you think? Should we file an RFE against sssd?
We already have https://pagure.io/SSSD/sssd/issue/3933 (and https://pagure.io/SSSD/sssd/issue/3932 for non-IPA docs)
Log in to comment on this ticket.