Tom,
You were right. According to the trace msg[0] is null.
(gdb) set follow-fork-mode child
(gdb) c
Continuing.
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5a6c2b77b0 (LWP 23208)]
0x0000000000580cf4 in pam_passwd_conv_proc (num_msg=0, msg=0x21015a0,
resp=0x7fff5955a0b8, appdata_ptr=0x7f20c7) at auth.c:1868
1868 auth.c: No such file or directory.
in auth.c
(gdb) backtrace
#0 0x0000000000580cf4 in pam_passwd_conv_proc (num_msg=0, msg=0x21015a0,
resp=0x7fff5955a0b8, appdata_ptr=0x7f20c7) at auth.c:1868
#1 0x00007f59e36f8dd8 in _pam_krb5_conv_call (pamh=<value optimized out>,
messages=0x2101490, n_prompts=0, responses=0x7fff5955a0b8) at conv.c:99
#2 0x00007f59e36f9b38 in _pam_krb5_generic_prompter (
context=<value optimized out>, data=0x7fff5955ba30,
name=<value optimized out>, banner=<value optimized out>, num_prompts=1,
prompts=<value optimized out>, suppress_password_prompts=1)
at prompter.c:330
#3 0x00007f59e36f9e10 in _pam_krb5_normal_prompter (context=0x0,
data=0x21015a0, name=0x7fff5955a0b8 "", banner=0x7f20c7 "",
num_prompts=0, prompts=0x101010101010101) at prompter.c:409
#4 0x00000031d3660bce in krb5_get_as_key_password (context=0x20fe420,
client=<value optimized out>, etype=23, prompter=<value optimized out>,
prompter_data=<value optimized out>, salt=0x7fff5955a950,
params=0x7fff5955a940, as_key=0x7fff5955a910, gak_data=0x7fff5955ab70)
at gic_pwd.c:61
#5 0x00000031d3667713 in pa_enc_timestamp (context=0x20fe420,
request=<value optimized out>, in_padata=<value optimized out>,
out_padata=0x7fff5955a780, salt=<value optimized out>,
s2kparams=<value optimized out>, etype=0x7fff5955a99c,
as_key=0x7fff5955a910,
prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>,
prompter_data=0x7fff5955ba30,
---Type <return> to continue, or q <return> to quit---
gak_fct=0x31d36609f0 <krb5_get_as_key_password>, gak_data=0x7fff5955ab70)
at preauth2.c:635
#6 0x00000031d3667e0c in krb5_do_preauth (context=<value optimized out>,
request=0x7fff5955a890, encoded_request_body=<value optimized out>,
encoded_previous_request=<value optimized out>, in_padata=0x2100ac0,
out_padata=<value optimized out>, salt=0x7fff5955a950,
s2kparams=0x7fff5955a940, etype=0x7fff5955a99c, as_key=0x7fff5955a910,
prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>,
prompter_data=0x7fff5955ba30,
gak_fct=0x31d36609f0 <krb5_get_as_key_password>, gak_data=0x7fff5955ab70,
get_data_rock=0x7fff5955a930, opte=0x20fe960) at preauth2.c:1586
#7 0x00000031d365f251 in krb5_get_init_creds (context=0x20fe420,
creds=<value optimized out>, client=<value optimized out>,
prompter=<value optimized out>, prompter_data=<value optimized out>,
start_time=<value optimized out>,
in_tkt_service=0x7fff5955baa0 "krbtgt/thexchange....@thexchange.com",
options=0x20fe960, gak_fct=0x31d36609f0 <krb5_get_as_key_password>,
gak_data=0x7fff5955ab70, use_master=0x7fff5955abac,
as_reply=0x7fff5955aba0) at get_in_tkt.c:1106
#8 0x00000031d3660f18 in krb5_get_init_creds_password (context=0x20fe420,
creds=<value optimized out>, client=<value optimized out>,
password=<value optimized out>,
prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>,
data=<value optimized out>, start_time=0, ---Type <return> to continue, or
q <return> to quit---
in_tkt_service=0x7fff5955baa0 "krbtgt/thexchange....@thexchange.com",
options=0x20fe960) at gic_pwd.c:139
#9 0x00007f59e36ff571 in v5_get_creds (ctx=0x20fe420,
pamh=<value optimized out>, creds=<value optimized out>,
user=<value optimized out>, userinfo=0x20fecf0, options=0x20fe9c0,
service=0x7f59e3703bf8 "krbtgt", password=0x0, gic_options=0x20fe960,
prompter=0x7f59e36f9e00 <_pam_krb5_normal_prompter>, result=0x21002d4)
at v5.c:1014
#10 0x00007f59e36f53cf in pam_sm_authenticate (pamh=0x210f5a0, flags=0,
argc=<value optimized out>, argv=<value optimized out>) at auth.c:423
#11 0x00000031d0202c1e in _pam_dispatch_aux (
use_cached_chain=<value optimized out>, resumed=<value optimized out>,
h=<value optimized out>, flags=<value optimized out>,
pamh=<value optimized out>) at pam_dispatch.c:110
#12 _pam_dispatch (use_cached_chain=<value optimized out>,
resumed=<value optimized out>, h=<value optimized out>,
flags=<value optimized out>, pamh=<value optimized out>)
at pam_dispatch.c:407
#13 0x00000031d0202500 in pam_authenticate (pamh=0x210f5a0, flags=0)
at pam_auth.c:34
#14 0x00000000005810d1 in CheckPAMAuth (user=<value optimized out>,
port=<value optimized out>, password=<value optimized out>) at auth.c:1999
#15 ClientAuthentication (user=<value optimized out>,
port=<value optimized out>, password=<value optimized out>) at auth.c:430
---Type <return> to continue, or q <return> to quit---
#16 0x00000000005e035c in BackendInitialize (port=0x20fd460)
at postmaster.c:3324
#17 0x00000000005e0c3c in BackendStartup (port=<value optimized out>)
at postmaster.c:3058
#18 ServerLoop (port=<value optimized out>) at postmaster.c:1387
#19 0x00000000005e354d in PostmasterMain (argc=1, argv=0x20b9010)
at postmaster.c:1040
#20 0x0000000000588900 in main (argc=1, argv=0x20b9010) at main.c:188
(gdb) print num_msg
$1 = 0
(gdb) print msg[0]
$2 = (const struct pam_message *) 0x0
(gdb)
-----Original Message-----
From: Magnus Hagander [mailto:mag...@hagander.net]
Sent: Friday, October 16, 2009 2:05 PM
To: Tom Lane
Cc: Douglas, Ryan; pgsql-bugs
Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5
2009/10/16 Tom Lane <t...@sss.pgh.pa.us>:
> I wrote:
>> The best idea I can come up with is that the conv_proc is being called
>> with zero messages and is dumping core because it tries to print the
>> contents of msg[0]. However, it's far from clear why libpam would
>> bother to call it with zero messages.
>
> Hah --- found it. (Man, it is so nice working with open source that
> you can actually look at...) prompter.c in pam_krb5 has
>
> /* Skip any prompt for which the supplied default answer is the
> * previously-entered password -- it's just a waste of the
> * user's time. */
>
> So it definitely is possible to call our proc with zero messages, and
> whether this will happen or not is probably dependent on the behavior
> of the KDC, and even then, ereport might or might not dump core depending
> on the contents of the not-allocated msg[0] array member.
>
> I will go and rewrite this function to look more like openssh's,
> on the assumption that their version is probably pretty well battle
> tested.
Yeah, that sounds like a reasonable thing to do.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
