Skip site navigation (1) Skip section navigation (2)

Re: BUG #5121: Segmentation Fault when using pam w/ krb5

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Douglas, Ryan" <RDouglas(at)arbinet(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5121: Segmentation Fault when using pam w/ krb5
Date: 2009-10-16 18:04:53
Message-ID: 9837222c0910161104k1ed87180g11c2be08b50cb311@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
2009/10/16 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/

In response to

Responses

pgsql-bugs by date

Next:From: Robert HaasDate: 2009-10-16 18:32:00
Subject: Re: BUG #5118: start-status-insert-fatal
Previous:From: Kevin GrittnerDate: 2009-10-16 18:04:15
Subject: Re: BUG #5118: start-status-insert-fatal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group