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

Re: psql with GSS can crash

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql with GSS can crash
Date: 2010-02-25 14:17:54
Message-ID: 9837222c1002250617h4279b579r9f100f411888a88@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:
> Hi all,
>
> I got following stack:
>
>  fffffd7ffed14b70 strlen () + 40
>  fffffd7ffed71665 snprintf () + e5
>  fffffd7fff36d088 pg_GSS_startup () + 88
>  fffffd7fff36d43a pg_fe_sendauth () + 15a
>  fffffd7fff36e557 PQconnectPoll () + 3b7
>  fffffd7fff36e152 connectDBComplete () + a2
>  fffffd7fff36dc32 PQsetdbLogin () + 1b2
>  000000000041e96d main () + 30d
>  000000000041302c ???????? ()
>
> It seems that connection is not fully configured and krbsrvname or pghost is
> not filled. Following code in fe-auth.c pg_GSS_startup() causes a crash:
>
>    440         maxlen = NI_MAXHOST + strlen(conn->krbsrvname) + 2;
>    441         temp_gbuf.value = (char *) malloc(maxlen);
>    442         snprintf(temp_gbuf.value, maxlen, "%s(at)%s",
>    443                          conn->krbsrvname, conn->pghost);
>    444         temp_gbuf.length = strlen(temp_gbuf.value);
>
> And following code in fe-connect.c fillPGconn() fill NULL value.
>
>    571         tmp = conninfo_getval(connOptions, "krbsrvname");
>    572         conn->krbsrvname = tmp ? strdup(tmp) : NULL;
>
> I think that pg_GSS_startup should sanity the input.

How did you get NULL in there? :-)
There's a default set for that one that's PG_KRB_SRVNAM, so it really
should never come out as NULL, I think...

As for pghost, that certainly seems to be a bug. We check that one in
krb5 and SSPI, but for some reason we seem to be missing it in GSSAPI.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-25 14:27:25
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Zdenek KotalaDate: 2010-02-25 14:04:17
Subject: psql with GSS can crash

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