[systemd-bugs] [Bug 67288] New: console login no longer possible when PAM_SESSION_ERR condition is triggered

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67288

          Priority: medium
            Bug ID: 67288
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: console login no longer possible when PAM_SESSION_ERR
                    condition is triggered
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: major
    Classification: Unclassified
                OS: All
          Reporter: mbiebl at gmail.com
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

Created attachment 82975
  --> https://bugs.freedesktop.org/attachment.cgi?id=82975&action=edit
simulate error condition in pam_systemd

Version: 204
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717772

While investigating [1], I noticed, that when an error condition occurs and
pam_systemd returns  PAM_SESSION_ERR, I am no longer able to log in on the
console. I'm immediately thrown back to the console. In the journal, I get the
following log messages:

> Jul 20 14:08:08 pluto login[3476]: pam_unix(login:session): session opened for user michael by LOGIN(uid=0)
> Jul 20 14:08:08 pluto systemd-logind[5664]: New session 13 of user michael.
> Jul 20 14:08:08 pluto login[3476]: pam_systemd(login:session): Failed to parse message: Message has only 5 arguments, but more were expected
> Jul 20 14:08:08 pluto systemd-logind[5664]: Removed session 13.
> Jul 20 14:08:08 pluto systemd[1]: getty at tty2.service holdoff time over, scheduling restart.
> Jul 20 14:08:08 pluto systemd[1]: Stopping Getty on tty2...
> Jul 20 14:08:08 pluto systemd[1]: Starting Getty on tty2...
> Jul 20 14:08:08 pluto systemd[1]: Started Getty on tty2.

I initially noticed this behaviour, when there was version mismatch
(libpam-systemd v204 talking to logind v44). But this is a general problem,
since there are various places in the code, where an error condition can occur.
To simplify this, I wrote a tiny patch, which simulates an error condition in
pam_sm_open_session(). If I apply that on top of v204, I'm also able to
reproduce this behaviour on a Fedora 19 box.

The pam configuration has 
 session  optional pam_systemd.so

A failing pam_systemd shouldn't cause the complete PAM stack to fail.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=67131

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20130725/4af80a27/attachment.html>