https://bugzilla.mindrot.org/show_bug.cgi?id=2475
Peter Urbanec <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla.mindrot.org@urbane | |c.net --- Comment #2 from Peter Urbanec <[email protected]> --- I have spent some time looking at this issue from the Linux PAM stack end. It looks like the problem is actually caused by openssh calling PAM from different threads/processes. Here is the rough sequence of what happens, with the thread id inside {} at the start of each line: {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(108)] called. {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(176)] user=root, password=[] {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)] recording return code for next time [7] {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)] done. [Authentication failure] {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(108)] called. {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(176)] user=root, password=[1] {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)] recording return code for next time [0] {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_authenticate(182)] done. [Success] {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(196)] called. {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(202)] user = `root' {12574}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_acct.c:pam_sm_acct_mgmt(307)] all done {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(203)] called. {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(209)] recovering return code from auth call {12568}[../../../Linux-PAM-1.3.0/modules/pam_unix/pam_unix_auth.c:pam_sm_setcred(217)] recovered data indicates that old retval was 7 This translates to: Thread 1 tries to authenticate with empty password This fails and the failure is cached in thread 1 context Thread 2 tries to authenticate again, this time with the password that the user supplied This succeeds and the success is cached in thread 2 context Thread 1 tries to set credentials, which uses the cached failure from thread 1 The call to pam_sm_setcred() should have come from the same thread that performed the successful call to pam_sm_authenticate() It looks like thread 2 has been forked from thread 1, because when it's called, it knows about the previous auth failure and it correctly replaces the previous (failure) return code with the new (success) return code. However, the parent process can never see this updated result code and instead only sees the previous failure. I have not had the chance to explore the openssh code yet, but it looks like the kind of thing that PrivSep would be involved in. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
