Mailing List Archive

http://bugzilla.mindrot.org/show_bug.cgi?id=688





------- Additional Comments From paul.a.bolton@bt.com 2003-09-19 20:23 -------
Created an attachment (id=434)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=434&action=view)
pam_dhkeys debug option

This shows that the module is not finding any keys from NIS+.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=688





------- Additional Comments From paul.a.bolton@bt.com 2003-09-22 01:09 -------
After looking at the problem today, I believe I have found the source of the
problem.

auth-pam.c spawns processes in order to perform the authentication and
credential setting in sub-processes. The workaround I have used is to force the
use of USE_POSIX_THREADS and use -lpthread.

As an example. in.telnetd will call pam_sm_authenticate() and then fork. Using
the same PAM handle, the child will then perform a pam_sm_setcred() and then
exec to the shell.

What sshd is doing is the main process (A) initializes the PAM framework, then
by simulating "pthreads" process A spawns a process B. Process B performs the
pam_sm_authenticate(). Sometime later A spawns a process C. Process C performs
the pam_sm_setcred(). Then A spawns D to exec and become the shell.
pam_sm_setcred (according to truss) seems to also be called in D. The problem is
that any module specific data set calling pam_sm_authenticate() and
pam_sm_setcred() are in separate copies of the PAM handle (i.e. in B,C,D). It
seems that there is something that is set at each stage that the other
components rely upon. Most likely it is becuase the password is stored in B (via
pam_set_item(...,PAM_AUTHTOK,...)), and hence C or D cannot perform the keylogin
(in pam_sm_setcred) as the password is not present in the module data defined
via the PAM handle.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.