Re: libpam-heimdal

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Brian" == Brian May <bam@snoopy.apana.org.au> writes:

    Brian> [529] [scrooge:bam] ~/source/debian/libpam-heimdal/cvs >cvs
    Brian> -d:pserver:anonymous@cvs.pam.sourceforge.net:/cvsroot/pam
    Brian> login Logging in to
    Brian> :pserver:anonymous@cvs.pam.sourceforge.net:2401/cvsroot/pam
    Brian> CVS password: cvs login: authorization failed: server
    Brian> cvs.pam.sourceforge.net rejected access to /cvsroot/pam for
    Brian> user anonymous

I solved this problem (which probably was my end - on my first try I
entered no password, and come up with an error "cannot read .cvspass",
so on my next try I entered "anonymous" as the userid, and got this
error).

However, the login process is still creating segment faults, in the same
place.


OLD CRASH:

Starting program: /bin/login 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
snoopy login: bam
Password: 
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
mcc_get_next (context=0x806d438, id=0x8067058, cursor=0xbfffd3d4, 
    creds=0xbfffd3b8) at mcache.c:270
270		*cursor = l->next;

The stack of the crashed process show (with debugging enabled in
libkrb5):

#0  mcc_get_next (context=0x806d438, id=0x8067058, cursor=0xbfffd3d4, 
    creds=0xbfffd3b8) at mcache.c:270
#1  0x40254417 in krb5_cc_next_cred (context=0x806d438, id=0x8067058, 
    cursor=0xbfffd3d4, creds=0xbfffd3b8) at cache.c:382
#2  0x401b0b4c in compat_cc_next_cred () from /lib/security/pam_krb5.so
#3  0x401afa0f in pam_sm_setcred () from /lib/security/pam_krb5.so
#4  0x40051926 in pam_fail_delay () from /lib/libpam.so.0
#5  0x40051bd4 in _pam_dispatch () from /lib/libpam.so.0
#6  0x4005353c in pam_setcred () from /lib/libpam.so.0
#7  0x804b244 in strcpy ()
#8  0x4007c38b in __libc_start_main () from /lib/libc.so.6

l is invalid:

(gdb) print l
$1 = (struct link *) 0x2

(gdb) print *l
Cannot access memory at address 0x2

l came from *cursor:

(gdb) print cursor
$2 = (krb5_cc_cursor *) 0xbfffd3d4
(gdb) print *cursor
$3 = 0x2

NEW CRASH:

(gdb) bt
#0  mcc_get_next (context=0x806d898, id=0x80672e0, cursor=0xbfffd3d4, 
    creds=0xbfffd3b8) at mcache.c:270
#1  0x40254417 in krb5_cc_next_cred (context=0x806d898, id=0x80672e0, 
    cursor=0xbfffd3d4, creds=0xbfffd3b8) at cache.c:382
#2  0x401b28b8 in compat_cc_next_cred () from /lib/security/pam_krb5.so
#3  0x401b083c in pam_sm_setcred () from /lib/security/pam_krb5.so
#4  0x40051926 in pam_fail_delay () from /lib/libpam.so.0
#5  0x40051bd4 in _pam_dispatch () from /lib/libpam.so.0
#6  0x4005353c in pam_setcred () from /lib/libpam.so.0
#7  0x804b244 in strcpy ()
#8  0x4007c38b in __libc_start_main () from /lib/libc.so.6

oh, oops, it looks exactly the same to me. Funny, before I enabled
debugging, this is what I consistently got:

Program received signal SIGSEGV, Segmentation fault.
0x402654e0 in krb5_log () from /usr/lib/libkrb5.so.16
(gdb) bt
#0  0x402654e0 in krb5_log () from /usr/lib/libkrb5.so.16
#1  0x40254317 in krb5_cc_next_cred () from /usr/lib/libkrb5.so.16
#2  0x401b28b8 in compat_cc_next_cred () from /lib/security/pam_krb5.so
#3  0x401b083c in pam_sm_setcred () from /lib/security/pam_krb5.so
#4  0x40051926 in pam_fail_delay () from /lib/libpam.so.0
#5  0x40051bd4 in _pam_dispatch () from /lib/libpam.so.0
#6  0x4005353c in pam_setcred () from /lib/libpam.so.0
#7  0x804b244 in strcpy ()
#8  0x4007c38b in __libc_start_main () from /lib/libc.so.6

Now, for the really annoying part: if I turn on -g when linking
pam_krb5.so.... It doesn't crash....

(it doesn't work either, but this could be another problem with the
newer code:

[501] [snoopy:unstable:bam] ~ >klist 
Credentials cache: FILE:/tmp/krb5cc_1003
        Principal: bam@CHOCBIT.ORG.AU

  Issued    Expires    Principal
[end-of output])
-- 
Brian May <bam@snoopy.apana.org.au>