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

Re: krb5 & multiple users

From: Ed Schaller <schallee(at)darkmist(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ed Schaller <schallee+postgres(at)darkmist(dot)net>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: krb5 & multiple users
Date: 2002-05-20 19:20:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
> Hmm.  Can we rearrange things so that fe_getauthname is not called till
> later?  I fail to see why it'd be a good idea to be sucking any kerberos
> info in at all during PQconndefaults, so the above suggests to me that
> we've divided up the operations wrongly.

The best way to do this would be to keep the authentication in PGconn or
a sub-struct of that. Then this could be passed down to any functions
that need the information contained there. The reason that the kerberos
stuff is needed for fe_getauthname is that it is possible for the user
name to only be defined in the kerberos credentials that are available.
The problem is that there is no way to share information between the
fe_sendauth and fe_getauthname as they have no common arguments. This
problem is fixed in this case by the static variables. 

Attached is a patch from the default cvs branch that fixes this problem.
It basically follows the third method from my previous email. It will
go and get the kerberos credentials every time fe_getauthname and
fe_sendauth are called. In most cases this will not actually add any
additional overhead.

I have not extensively tested the patch, but it does solve my double
connection test case. If others could test it I would appreciate it.

> BTW you might want to get Bear Giles involved in this, as he seems to be
> thinking hard about authentication issues in libpq.

I'd be happy to. Do you know his email address?



| Ed Schaller | schallee(at)darkmist(dot)net | mistymushroom |

In response to

pgsql-interfaces by date

Next:From: Corey W. GibbsDate: 2002-05-20 21:53:29
Subject: Is there a limit on what can be returned?
Previous:From: Gareth KirwanDate: 2002-05-20 16:40:46
Subject: Re: Interval to number

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