FS#32559 - [pam] [pam_ldap] Using pam_ldap in the PAM stack breaks systemd-logind session handling
Attached to Project:
Arch Linux
Opened by Moritz Bunkus (mbunkus) - Friday, 09 November 2012, 10:39 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 10 June 2014, 13:52 GMT
Opened by Moritz Bunkus (mbunkus) - Friday, 09 November 2012, 10:39 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 10 June 2014, 13:52 GMT
|
Details
Description:
As soon as pam_ldap.so is listed in the PAM authentication stack systemd-logind does not handle the sessions anymore. This applies to both graphical logins as well as console logins. This is a fully "pacman -Syu"ed system running pure systemd. I'm using KDE with KDM as the login manager. My setup is the usual LDAP-based client setup as described in e.g. https://wiki.archlinux.org/index.php/OpenLDAP_Authentication#Client_Setup What I did: - installed nss_ldap, pam_ldap - configured /etc/nss_ldap.conf, /etc/pam_ldap.conf - made first sure all files in /etc/pam.d are identical to originals from packages (especially pambase with "system-login" etc.), then: - configured pam_ldap in /etc/pam.d/system-auth with "servicename sufficient pam_ldap.so" lines before each "servicename required pam_unix.so..." line - test NSS with "getent passwd", both local and remote users are listed - LDAP users: test PAM by logging in with an LDAP user on the console and in KDE via KDM - "loginctl" shows 0 active sessions - local users: test PAM by logging in with a local user on the console and in KDE via KDM - "loginctl" still shows 0 active sessions Now in order to test whether or not pam_ldap is the culprit I additionally did: - removed the lines from /etc/pam.d/system-auth that I've just added and made sure all files in /etc/pam.d are identical to their original versions - logged in again on the console and in KDE via KDM with the same local user I've used in the test above - "loginctl" now shows two active sessions Additional info: * involed packages: pambase 20120701-1 ; pam_ldap 186-4 ; nss_ldap 265-4 ; systemd 195-2 ; kdebase-workspace 4.9.2-6 (for KDM) * /etc/pam.d/system-auth with active pam_ldap.so: #%PAM-1.0 auth required pam_env.so auth sufficient pam_ldap.so auth required pam_unix.so try_first_pass nullok auth optional pam_permit.so account sufficient pam_ldap.so account required pam_unix.so account optional pam_permit.so account required pam_time.so password sufficient pam_ldap.so password required pam_unix.so try_first_pass nullok sha512 shadow password optional pam_permit.so session required pam_limits.so session required pam_env.so session sufficient pam_ldap.so session required pam_unix.so session optional pam_permit.so * /etc/pam_ldap.conf (only lines that aren't commented out): host 192.168.10.3 base dc=mycompany,dc=ucs rootbinddn cn=admin,dc=mycompany,dc=ucs ssl start_tls tls_checkpeer no * /etc/nss_ldap.conf is identical to pam_ldap.conf I'll be happy to post any other configuration file or content from journalctl (which does not show ANYTHING interesting). Other users seem to have the same problem. Here's a forum post from someone else who describes pretty much what I've experienced (though I haven't played around with the groups): https://bbs.archlinux.org/viewtopic.php?pid=1185596 Steps to reproduce: see bullet list above |
This task depends upon
Here's what I suspect happens.
Most tutorials on the web (including the ones in Arch's wiki for LDAP/OpenLDAP authentication, and including the documentation for pam_ldap and nss-pam-ldapd) have suggested using entries in /etc/pam.d/* that look like this for ages: 'servicename sufficient pam_ldap.so' right before 'servicename required pam_unix.so try_first_pass'. This is fine as long as no other important module is located later in the stack for that very same service. The reason why this must not be the case is that a successful result of a module flagged with action 'sufficient' will terminate all further processing for that service.
Unfortunately, in Arch the two 'session' services for consolekit and systemd are located at the very bottom of the PAM stack: system-login contains both pam_ck-... and pam_systemd, but before those lines it includes system-auth. system-auth in turn contains pam_unix.so and therefore most users will simply put pam_ldap.so into system-auth as well -- with the action being 'sufficient'.
There are two things which can be done in order to improve this:
1. The user (and only the user) can use '[ok=1]' as the action for pam_ldap.so. That will skip the next service, most likely this is 'pam_unix.so', and return 'success' from the PAM stack while still processing the rest of the PAM stack.
2. Both the user and the Arch maintainers could move the 'include system-auth' directive to the bottom of the PAM stack (for /etc/pam.d/sshd similar things can be done: move pam_ck-... and pam_systemd.so before pam_unix.so). This would make it a bit harder for unsuspecting users to fall into this trap accidenally. I've checked and found that Fedora Core 17 does it exactly like this. Their /etc/pam.d/system-auth looks like this:
session optional pam_keyinit.so revoke
session required pam_limits.so
-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
If all this speculation turns out to be correct then I'd re-file the bug against pambase and the other packages so that they might be made aware of the issue and can consider moving pam_systemd.so up a bit. This is also not limited to pam_ldap but can occur for any module flagged 'sufficient' and being in the 'session' service stack, but it is most likely to happen with modules that implement authenticating users that're stored in a remote service (LDAP, Windows AD etc).
Please don't spend too much time on it until I've verified my assumptions.
-------------------------------------------
#%PAM-1.0
auth required pam_env.so
auth [success=1 default=ignore] pam_ldap.so
auth required pam_unix.so try_first_pass nullok
auth optional pam_permit.so
account [success=1 default=ignore] pam_ldap.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
password [success=1 default=ignore] pam_ldap.so
password required pam_unix.so try_first_pass nullok sha512 shadow
password optional pam_permit.so
session required pam_limits.so
session required pam_env.so
session [success=1 default=ignore] pam_ldap.so
session required pam_unix.so
session optional pam_permit.so
-------------------------------------------
Logging in via console and via KDM works both with local pam_unix authenticated users as well as users stored in LDAP. Login with unknown user names does not work, login with valid user names but wrong passwords doesn't work either -- works just like it should.
After loggin in "loginctl" shows the active session properly, both in the console and via KDM.
So please re-file against pambase. Thanks.