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
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Dec 12 02:10:03 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator: Thomas E. Spanjaard
>Release: 9.0-CURRENT
>Organization:
>Environment:
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
>Description:
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;
524
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.
>How-To-Repeat:
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 ;)).
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list