https://bugzilla.novell.com/show_bug.cgi?id=823484 https://bugzilla.novell.com/show_bug.cgi?id=823484#c0 Summary: pam_ssh stays as user if no session tty Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: i586 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jimc@math.ucla.edu QAContact: qa-bugs@suse.de Found By: Community User Blocker: --- Versions: OpenSuSE 12.3 (final) pam_ssh-1.97-23.1.1.i586 and x86_64 xdm-1.1.10-14.6.1.i586 and x86_64 Also seen with: OpenSuSE 11.4 dated 2011-03-02 pam_ssh-1.97-11.14.1.i586 xorg-x11-7.6-43.46.1.i586 (for /usr/bin/xdm) How to reproduce: Execute as a user having SSH keys, i.e. ~/.ssh/id_rsa and friends. Users lacking SSH keys do not experience the bug. Configure the server's PAM session script to include: session optional pam_ssh.so debug ("debug" does not affect the bug but helps debugging.) Set up XDM on the server to accept XDMCP queries, remote or local. Start an X-server that makes a XDMCP query, for example: /usr/bin/Xvnc -inetd -port 177 -query localhost -once -geometry 1024x768 -depth 16 SecurityTypes=None It fails equally with Xephyr and with XMing on Windows. What result is expected: XDM puts up a greeter, the user authenticates, XDM runs /etc/X11/xdm/Xsession, and the user gets a session. What actually happens: XDM puts up a greeter, the user authenticates, and the session ends at that point. These messages are seen on syslog: (snip) Jun 2 10:53:43 iris xdm[4896]: pam_krb5[4896]: authentication succeeds for 'jimc' (jimc@CFT.CA.US) Jun 2 10:53:43 iris pam_ssh[4896]: init authentication module Jun 2 10:53:44 iris pam_ssh[4896]: auth successful for key id_rsa Jun 2 10:53:44 iris pam_ssh[4896]: auth successful for key id_rsa_mathroot Jun 2 10:53:44 iris pam_ssh[4896]: open session Jun 2 10:53:44 iris pam_ssh[4909]: exec /usr/bin/ssh-agent Jun 2 10:53:44 iris pam_ssh[4896]: session has no tty Jun 2 10:53:44 iris .ca[4896]: pam_lastlog(xdm:session): unable to open /var/lo g/lastlog: Permission denied Jun 2 10:53:44 iris .ca[4896]: PAM audit_log_acct_message() failed: Operation n ot permitted Jun 2 10:53:44 iris dbus-daemon[784]: dbus[784]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.43" (uid=500 pid=4911 comm="-iris.cft.ca ") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=696 comm="/usr/lib/systemd/systemd-logind ") Jun 2 10:53:44 iris dbus[784]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.43" (uid=500 pid=4911 comm="-iris.cft.ca ") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=696 comm="/usr/lib/systemd/systemd-logind ") Jun 2 10:53:44 iris .ca[4911]: pam_systemd(xdm:session): Failed to release session: Access denied Jun 2 10:53:44 iris .ca[4911]: pam_mail(xdm:session): pam_putenv: delete non-existent entry; MAIL Jun 2 10:53:44 iris dbus-daemon[784]: dbus[784]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.44" (uid=500 pid=4896 comm="-iris.cft.ca ") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=696 comm="/usr/lib/systemd/systemd-logind ") Jun 2 10:53:44 iris dbus[784]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.44" (uid=500 pid=4896 comm="-iris.cft.ca ") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=696 comm="/usr/lib/systemd/systemd-logind ") Jun 2 10:53:44 iris .ca[4896]: pam_systemd(xdm:session): Failed to release session: Access denied Strace reveals that XDM's session shepherd sets eUID to the user and puts it back to root, several times, but finally sets eUID to the user, forks and starts the agent, writes into ~/.ssh/agent-$HOST, sends to syslog a message beginning with "pam_ssh", and doesn't set eUID back to root. Subsequent steps fail because the user lacks permission to do them. How to fix: In pam_ssh.c, pam_sm_authenticate and pam_sm_close_session call openpam_borrow_cred but all ways out of the subroutines include openpam_restore_cred. However in pam_sm_open_session there are two points where you can escape without callling openpam_restore_cred: if you can read the agent file but can't stat it, and if you're about to link $HOME/.ssh/agent-$HOST-$TTY but there is no tty. The latter is my case. The included patch plugs both these escape routes, and the user can now get a session. More suggestions from the developers: Other display managers like LightDM do not trigger this bug. Do you suppose they pre-emptively set eUID back to root, knowing that PAM modules sometimes fail to do it? Such a defensive strategy might be a good idea for XDM. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.