kinit locking up

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

kinit locking up

Jon DeVree
I recently upgraded from kerberos5 1.3.6 to 1.4.3 (Debian packages)
and now kinit has some interesting behavior. I think this is also why
SSH behaves strangely on my system now.
                                                                                $ kinit jon@SETEC
Password for jon@SETEC:
$ kdestroy
$ kinit
Password for jon@SETEC:
*hangs forever after password is entered*

If I already have a tgt and run just "kinit" it works perfectly fine.

The lockup comes from the mutex lock run in krb5_fcc_initialize and            
seems to be directly related to having to call getpwuid() when I don't          
supply my username and it can't look in a pre-existing ticket cache for        
one.

--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Russ Allbery
Jon DeVree <[hidden email]> writes:

> I recently upgraded from kerberos5 1.3.6 to 1.4.3 (Debian packages)
> and now kinit has some interesting behavior. I think this is also why
> SSH behaves strangely on my system now.

> $ kinit jon@SETEC
> Password for jon@SETEC:
> $ kdestroy
> $ kinit
> Password for jon@SETEC:
> *hangs forever after password is entered*

If you run kinit under strace, what is it doing after you enter your
password?  Nothing at all?

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
On Sat, Dec 10, 2005 at 03:32:27PM -0800, Russ Allbery wrote:
> If you run kinit under strace, what is it doing after you enter your
> password?  Nothing at all?
>

connect(4, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.0.3.1")}, 28) = 0
fcntl64(4, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
gettimeofday({1134262677, 201560}, NULL) = 0
poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
send(4, "\307\300\1\0\0\1\0\0\0\0\0\0\5tesla\5setec\0\0\1\0\1", 29, 0) =
29
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(4, FIONREAD, [59])                = 0
recvfrom(4, "\307\300\205\200\0\1\0\1\0\1\0\0\5tesla\5setec\0\0\1\0"...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.0.3.1")}, [16]) = 59
close(4)                                = 0
gettimeofday({1134262677, 204715}, NULL) = 0
time(NULL)                              = 1134262677
futex(0x804d2f4, FUTEX_WAIT, 2, NULL)   = -1 EINTR (Interrupted system
call)

Of course I Ctrl+C'd kinit after a few seconds.
--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Russ Allbery
In reply to this post by Jon DeVree
Jon DeVree <[hidden email]> writes:

> futex(0x804d2f4, FUTEX_WAIT, 2, NULL)   = -1 EINTR (Interrupted system
> call)

> Of course I Ctrl+C'd kinit after a few seconds.

Well, huh.

Of course, I can't manage to reproduce this (or I wouldn't have uploaded
the new Kerberos packages to Debian until I got to the bottom of it).  I'm
rather unclear as to what could be going on, or why it would be sensitive
to whether or not you gave your principal name on the command line.

Out of curiousity, if it's easy for you, could you install the kstart
package and try obtaining a ticket with k5start?  It should work basically
like kinit, but it's an independent implementation.  That should isolate
whether it's some sort of library problem or possibly a problem in kinit
itself.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
On Sat, Dec 10, 2005 at 05:36:06PM -0800, Russ Allbery wrote:

> Jon DeVree <[hidden email]> writes:
>
> > futex(0x804d2f4, FUTEX_WAIT, 2, NULL)   = -1 EINTR (Interrupted system
> > call)
>
> > Of course I Ctrl+C'd kinit after a few seconds.
>
> Of course, I can't manage to reproduce this (or I wouldn't have uploaded
> the new Kerberos packages to Debian until I got to the bottom of it).  I'm
> rather unclear as to what could be going on, or why it would be sensitive
> to whether or not you gave your principal name on the command line.
>
Well as soon as I remove getpwuid() from the function that looks up my
username kinit works flawlessly although not terribly usefully.

>
> Out of curiousity, if it's easy for you, could you install the kstart
> package and try obtaining a ticket with k5start?  It should work basically
> like kinit, but it's an independent implementation.  That should isolate
> whether it's some sort of library problem or possibly a problem in kinit
> itself.
>
k5start seems to be working fine.
Also if I didn't mention it, pam_krb5 is working fine too.
SSH fails if it tries GSSAPIAuthentication. It locks up in the same futex
function presumably in the same spot of libkrb5.

--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
I noticed that my UltraSPARC box fails differently from the x86
boxes. While the failure still happens under the same circumstances the
UltraSPARC box gives an error message instead of locking up:

kinit(v5): Invalid argument when initializing cache

Like the x86 boxes if I already have a ticket or specifiy the principal
name on the command line it works.
--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Wyllys Ingersoll
Jon DeVree wrote:
>  I noticed that my UltraSPARC box fails differently from the x86
>  boxes. While the failure still happens under the same circumstances
>  the UltraSPARC box gives an error message instead of locking up:
>
>  kinit(v5): Invalid argument when initializing cache
>
>  Like the x86 boxes if I already have a ticket or specifiy the
>  principal name on the command line it works.


On the UltraSPARC, I assume you are running Solaris. In which case
you may be getting the Solaris 'kinit' in your path before the
MIT 'kinit'.   Solaris Kerberos looks for configuration files
in /etc/krb5/ where as MIT defaults to just putting them under /etc/
That is probably why it is failing to initialize - the Solaris
'kinit' is not finding the correct configuration file.  Ditto for
'ssh'.

2 Possible workarounds:
 - create softlinks from /etc/krb5/krb5.conf -> /etc/krb5.conf
 OR
 - make sure the MIT 'kinit' is in your path before the Solaris 'kinit'.

If you are running Solaris 10 you really don't need to install
MIT Kerberos, the system already has all of the Kerberos pieces
delivered and installed by default.  Try removing the MIT tools
and just use the Solaris default clients and see how that goes.


-Wyllys



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Kenneth G Raeburn
In reply to this post by Jon DeVree
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 10, 2005, at 19:58, Jon DeVree wrote:

> On Sat, Dec 10, 2005 at 03:32:27PM -0800, Russ Allbery wrote:
>> If you run kinit under strace, what is it doing after you enter your
>> password?  Nothing at all?
>
> connect(4, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("10.0.3.1")}, 28) = 0
> fcntl64(4, F_GETFL)                     = 0x2 (flags O_RDWR)
> fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> gettimeofday({1134262677, 201560}, NULL) = 0
> poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
> send(4, "\307\300\1\0\0\1\0\0\0\0\0\0\5tesla\5setec\0\0\1\0\1", 29,  
> 0) =
> 29
> poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
> ioctl(4, FIONREAD, [59])                = 0
> recvfrom(4, "\307\300\205\200\0\1\0\1\0\1\0\0\5tesla\5setec\0\0\1
> \0"...,
> 1024, 0, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("10.0.3.1")}, [16]) = 59
> close(4)                                = 0
> gettimeofday({1134262677, 204715}, NULL) = 0
> time(NULL)                              = 1134262677
> futex(0x804d2f4, FUTEX_WAIT, 2, NULL)   = -1 EINTR (Interrupted system
> call)

I'm not sure what mutex would be getting locked at that point.  If  
you're rebuilding binaries, could you try building with -g and get a  
stack trace in gdb when this happens?  If it's in one of the libkrb5  
mutex-handling macros, the mutex object we use should include a file  
name and line number where the mutex was last locked or unlocked;  
that would be useful to know too.

Ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDndYqUqOaDMQ+e5gRAtCrAJ9oqYU7T/HGDSqJNIRWruUVc+hbnACgyDJr
DrUuDDuP08XhTbbYnGsFMzY=
=Q3Yo
-----END PGP SIGNATURE-----
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
(gdb) run
Starting program: /tmp/krb5-1.4.3/build/clients/kinit/kinit
[Thread debugging using libthread_db enabled]
[New Thread -1210923328 (LWP 15332)]
Password for jon@SETEC:

Program received signal SIGINT, Interrupt.
[Switching to Thread -1210923328 (LWP 15332)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7c0257e in __lll_mutex_lock_wait ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7bff0d0 in _L_mutex_lock_29 () from
/lib/tls/i686/cmov/libpthread.so.0
#3  0xb7f30570 in ?? ()
#4  0xb7f46ff4 in ?? () from /lib/ld-linux.so.2
#5  0xb7f47508 in ?? ()
#6  0xb7f476b4 in ?? ()
#7  0xbf944af0 in ?? ()
#8  0xb7e5eff4 in ?? () from /lib/tls/i686/cmov/libc.so.6
#9  0x0804d2e0 in ?? ()
#10 0x0804d2f4 in ?? ()
#11 0xbf944ad8 in ?? ()
#12 0xb7e0afe6 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libc.so.6
#13 0xb7e0afe6 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libc.so.6
#14 0xb7ed7b4a in krb5_fcc_initialize (context=0x804d088, id=0x804d290,
    princ=0x8052c48) at ../../../../src/lib/krb5/ccache/cc_file.c:1423
#15 0xb7eda198 in krb5_cc_initialize (context=0x804d088,
cache=0xfffffffc,
    principal=0x8052c48) at ../../../../src/lib/krb5/ccache/ccfns.c:49
#16 0x0804a398 in main (argc=1, argv=0xbf9451c4)
    at ../../../src/clients/kinit/kinit.c:847

--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Kenneth G Raeburn
On Dec 13, 2005, at 16:20, Jon DeVree wrote:
> #13 0xb7e0afe6 in pthread_mutex_lock () from
> /lib/tls/i686/cmov/libc.so.6
> #14 0xb7ed7b4a in krb5_fcc_initialize (context=0x804d088,  
> id=0x804d290,
>     princ=0x8052c48) at ../../../../src/lib/krb5/ccache/cc_file.c:1423

1423:   kret = k5_mutex_lock(&((krb5_fcc_data *) id->data)->lock);

Could you show me what the "lock" field (a structure) contains at  
this point?  There should be a couple of fields indicating where the  
lock was previously acquired.

I've skimmed cc_file.c but didn't spot any place where we're likely  
to leave a mutex locked.  (Though I did spot one error path where we  
might destroy a locked mutex without unlocking it first, which should  
also be fixed.)

Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
[Switching to Thread -1210816832 (LWP 15431)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
*snip*
#12 0xb7e24fe6 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libc.so.6
#13 0xb7e24fe6 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libc.so.6
#14 0xb7ef1b4a in krb5_fcc_initialize (context=0x804d088, id=0x804d290,
    princ=0x8052c48) at ../../../../src/lib/krb5/ccache/cc_file.c:1423
#15 0xb7ef4198 in krb5_cc_initialize (context=0x804d088,
cache=0xfffffffc,
    principal=0x8052c48) at ../../../../src/lib/krb5/ccache/ccfns.c:49
#16 0x0804a398 in main (argc=1, argv=0xbfc5f4f4)
    at ../../../src/clients/kinit/kinit.c:847
(gdb) select 14
(gdb) print ((krb5_fcc_data *)id->data).lock
$1 = {loc_last = {
    filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
    lineno = 2085}, loc_created = {
    filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
    lineno = 1703}, os = {p = {__m_reserved = 2, __m_count = 1651665711,
      __m_owner = 0x6f632e35, __m_kind = 26222, __m_lock = {__status =
2217,
        __spinlock = -1209554792}}, owner = 0}, stats = 115 's'}

--
Jon
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

hartmans
Ken, FYI, the source is available either from the Debian archive or at
svn://svn-debian.suchdamage.org/svn-debian/krb5/trunk

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Kenneth G Raeburn
In reply to this post by Jon DeVree
Thanks...

> (gdb) print ((krb5_fcc_data *)id->data).lock
> $1 = {loc_last = {
>     filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
>     lineno = 2085},

So, the last action performed on this object by the krb5 mutex macros  
was an unlock in the MAYBE_OPEN macro's error handling path...

> loc_created = {
>     filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
>     lineno = 1703},

The mutex was initialized in krb5_fcc_resolve; that's normal.

> os = {p = {__m_reserved = 2, __m_count = 1651665711,
>       __m_owner = 0x6f632e35, __m_kind = 26222, __m_lock = {__status =
> 2217,
>         __spinlock = -1209554792}}, owner = 0}, stats = 115 's'}

This is not so normal.  The first few fields look like part of an  
ASCII string written over a data structure:

0x62726b2f = "brk/"
0x6f632e35 = "oc.5"

Or, reversing for little-endian values, "/krb5.co".  That suggests  
some memory corruption, or initialization not happening.  Could you  
try valgrind or electric fence and see if they spot any problems?

I'm trying some builds with the code Sam pointed me to, to see if I  
can reproduce the problem with the Debian source tree, though on the  
x86_64 system I tried I didn't see any futex calls being made at all...

Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
> This is not so normal.  The first few fields look like part of an  
> ASCII string written over a data structure:
>

I took some dumps from GDB from when it "worked" and just so you know:
os = {p = {__m_reserved = 1668572463, __m_count = 1651665711,
__m_owner = 0x6f632e35, __m_kind = 26222, __m_lock = {__status = 2217,
__spinlock = -1209583464}}, owner =0}

Those first 4 values work out to
/etc/krb5.conf

> Or, reversing for little-endian values, "/krb5.co".  That suggests  
> some memory corruption, or initialization not happening.  Could you  
> try valgrind or electric fence and see if they spot any problems?
>

I'll try that, never used them before though.

--
Jon
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Russ Allbery
In reply to this post by Jon DeVree
Jon DeVree <[hidden email]> writes:

>> Or, reversing for little-endian values, "/krb5.co".  That suggests  
>> some memory corruption, or initialization not happening.  Could you  
>> try valgrind or electric fence and see if they spot any problems?

> I'll try that, never used them before though.

Just apt-get install valgrind and then run:

    valgrind kinit

and it will spew out lots of memory debugging.  You can use the --log-file
option to specify a file to which the output should go instead.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
Attached is the output from valgrind.

--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

log.16877 (45K) Download Attachment
signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Russ Allbery
In reply to this post by Jon DeVree
Jon DeVree <[hidden email]> writes:

> Attached is the output from valgrind.

Below is the interesting bit.  valgrind at least thinks that the mutexes
aren't fully initialized, it looks like, before they're passed into the
pthread functions.  Note that I don't get these same errors when I run
valgrind against the kinit in unstable, so I'm curious about what's
different in your situation.

One thing that I did notice was a bunch of SASL calls earlier on.  I think
the invalid reads there are probably just the standard ld.so noise that
doesn't appear to mean anything, but their presence indicates that you're
using some nsswitch module (I'm guessing) that uses SASL.  Are you using
LDAP to do UID lookups, by any chance?

I don't know why that would affect things, but maybe it is.

> ==16877== Conditional jump or move depends on uninitialised value(s)
> ==16877==    at 0x444AF7A: pthread_mutex_lock (in /lib/tls/i686/cmov/libpthread-2.3.5.so)
> ==16877==    by 0x41C9FE5: pthread_mutex_lock (in /lib/tls/i686/cmov/libc-2.3.5.so)
> ==16877==    by 0x406DB49: krb5_fcc_initialize (cc_file.c:1423)
> ==16877==    by 0x4070197: krb5_cc_initialize (ccfns.c:49)
> ==16877==    by 0x804A397: (within /usr/bin/kinit)
> ==16877==    by 0x4100EAF: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.5.so)

[...]

> ==16877== Conditional jump or move depends on uninitialised value(s)
> ==16877==    at 0x444AF7A: pthread_mutex_lock (in /lib/tls/i686/cmov/libpthread-2.3.5.so)
> ==16877==    by 0x41C9FE5: pthread_mutex_lock (in /lib/tls/i686/cmov/libc-2.3.5.so)
> ==16877==    by 0x406D259: krb5_fcc_store (cc_file.c:2124)
> ==16877==    by 0x40701F7: krb5_cc_store_cred (ccfns.c:68)
> ==16877==    by 0x804AB5E: (within /usr/bin/kinit)
> ==16877==    by 0x4100EAF: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.5.so)

[...]

> ==16877== Conditional jump or move depends on uninitialised value(s)
> ==16877==    at 0x444AF7A: pthread_mutex_lock (in /lib/tls/i686/cmov/libpthread-2.3.5.so)
> ==16877==    by 0x41C9FE5: pthread_mutex_lock (in /lib/tls/i686/cmov/libc-2.3.5.so)
> ==16877==    by 0x406E075: dereference (cc_file.c:1485)
> ==16877==    by 0x406E2EE: krb5_fcc_close (cc_file.c:1503)
> ==16877==    by 0x40701D3: krb5_cc_close (ccfns.c:61)
> ==16877==    by 0x8049E3B: (within /usr/bin/kinit)
> ==16877==    by 0x4100EAF: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.5.so)

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Jon DeVree
On Wed, Dec 14, 2005 at 07:39:56PM -0800, Russ Allbery wrote:
> One thing that I did notice was a bunch of SASL calls earlier on.  I think
> the invalid reads there are probably just the standard ld.so noise that
> doesn't appear to mean anything, but their presence indicates that you're
> using some nsswitch module (I'm guessing) that uses SASL.  Are you using
> LDAP to do UID lookups, by any chance?
>

Yes and I just made a non-LDAP account with a kerberos principal and
kinit ran fine.

--
Jon
"Only in the tales that humans tell do the hunters kill the wolves in the end." -- Jin-Roh

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Russ Allbery
In reply to this post by Jon DeVree
Jon DeVree <[hidden email]> writes:
> On Wed, Dec 14, 2005 at 07:39:56PM -0800, Russ Allbery wrote:

>> One thing that I did notice was a bunch of SASL calls earlier on.  I
>> think the invalid reads there are probably just the standard ld.so
>> noise that doesn't appear to mean anything, but their presence
>> indicates that you're using some nsswitch module (I'm guessing) that
>> uses SASL.  Are you using LDAP to do UID lookups, by any chance?

> Yes and I just made a non-LDAP account with a kerberos principal and
> kinit ran fine.

Okay, getting closer.  What SASL modules do you have installed?  In
particular, do you have any GSSAPI SASL modules installed?

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kinit locking up

Kenneth G Raeburn
In reply to this post by Russ Allbery
On Dec 14, 2005, at 22:39, Russ Allbery wrote:

> Below is the interesting bit.  valgrind at least thinks that the  
> mutexes
> aren't fully initialized, it looks like, before they're passed into  
> the
> pthread functions.  Note that I don't get these same errors when I run
> valgrind against the kinit in unstable, so I'm curious about what's
> different in your situation.
>
> One thing that I did notice was a bunch of SASL calls earlier on.  
> I think
> the invalid reads there are probably just the standard ld.so noise  
> that
> doesn't appear to mean anything, but their presence indicates that  
> you're
> using some nsswitch module (I'm guessing) that uses SASL.  Are you  
> using
> LDAP to do UID lookups, by any chance?
>
> I don't know why that would affect things, but maybe it is.

Aha!  I think you may have put your finger on it, Russ.

Part of our approach to dealing with threads has been, when possible,  
to give the application writer the option of not linking in the  
pthread library, instead using weak references at run time to see if  
the library has been loaded.  We want programs to be able to  
dynamically load and unload the Kerberos and GSSAPI libraries without  
ill effects, and the general wisdom seems to be that dynamically  
loading a pthread library into a single-threaded program can do Bad  
Things, like cause different versions of malloc or other functions to  
be seen, when they may not be fully compatible with the versions  
already in use by the program.

So now we have another library being loaded somewhere along the way  
which causes the pthread library to be loaded (libnss_ldap ->  
libldap_r -> libpthread, on my system), and the Kerberos library is  
calling pthread_mutex_lock on a structure which it hasn't  
initialized, when the LDAP code is loaded.

The strange bit is, in 1.4.3, the Kerberos code should be checking  
for the thread support once, and saving away a flag; if it wasn't  
loaded at mutex initialization time, we shouldn't be calling  
pthread_mutex_lock.  If we call pthread_mutex_lock, we should've  
decided earlier to call pthread_mutex_init.  So I should do some  
poking around and see if I can figure out why we still seem to be  
behaving differently in the two cases.

In any case, I do think libnss_ldap may have a bug -- I don't think  
libpthread should be getting pulled into a single-threaded program  
dynamically.  Though, if it's guaranteed to be safe with glibc, and  
remain safe in future releases, we could consider a Linux- or glibc-
specific change to punt the weak-reference stuff and always pull in  
the pthread library ourselves...

Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
12