misc/141390: login(1) or PAM broken after -CURRENT upgrade

Thomas E. Spanjaard tgen at deepbone.net
Sat Dec 12 02:10:03 UTC 2009

>Number:         141390
>Category:       misc
>Synopsis:       login(1) or PAM broken after -CURRENT upgrade
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 12 02:10:03 UTC 2009
>Originator:     Thomas E. Spanjaard
>Release:        9.0-CURRENT
FreeBSD ara.ssr.netphreax.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r200414: Fri Dec 11 20:02:44 UTC 2009     tgen at ara.ssr.netphreax.net:/usr/obj/usr/home/tgen/Work/FreeBSD-HEAD/sys/ARA  amd64

login(1) doesn't work anymore after I updated my system (late October 9.0-CURRENT) as per the procedure outlined in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html . login(1) invariably segfaults if you enter the right credentials, making logins on the console impossible. SSH still works, which is how I was able to get the following information:

Program received signal SIGSEGV, Segmentation fault.
0x0000000800a55d08 in strncpy () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800a55d08 in strncpy () from /lib/libc.so.7
#1  0x0000000801a44b0e in ulog_login () from /lib/libulog.so.0
#2  0x0000000801941d66 in pam_sm_open_session () from /usr/lib/pam_lastlog.so.5
#3  0x000000080076159a in openpam_dispatch () from /usr/lib/libpam.so.5
#4  0x0000000000403574 in main (argc=0, argv=0x7fffffffeb08)
    at /usr/home/tgen/Work/FreeBSD-HEAD/usr.bin/login/login.c:525
(gdb) list 525
520			pam_syslog("pam_setcred()");
521			bail(NO_SLEEP_EXIT, 1);
522		}
523		pam_cred_established = 1;
525		pam_err = pam_open_session(pamh, pam_silent);
526		if (pam_err != PAM_SUCCESS) {
527			pam_syslog("pam_open_session()");
528			bail(NO_SLEEP_EXIT, 1);
529		}

Smells like a null pointer dereference, but where and why I have no idea. As SSH logins work, and I assume that uses PAM as well, the problem must be elsewhere. Mergemaster was tedious, as it complained about all sorts of files in /etc having CVS Ids instead of SVN ones, including /etc/login.*. I did run a cap_mkdb though, so that shouldn't be the problem.
Ostensibly, updating a late October 9.0-CURRENT system to HEAD. After a reboot, console logins shouldn't work anymore (well, they should, but don't... you get what I mean ;)).


More information about the freebsd-bugs mailing list