Re: krb5 & multiple users

I am trying to connect to the database multiple times with different
user accounts using kerberos. Unfortunately the current libpq libraries
keep all of the kerberos credentials and such in static variables that
are used for all subsequent connections. After changing to a different
user, all authentications fail since it is trying to use the previous
credentials.

Looking at the source code, I figured I could just move the the static
vars to the PGconn structure. As I did it turned out that the conn
structure was not available where it was needed, so I thought I would
post here for suggestions.

The options I am looking at are:

Add it to the PGconn structure and pull it in where it is needed. This
would require some api changes.

Keep a hash of the usernames in static space and use the right
credentials for the right user. This would fix the problem, but it would
require extra data structures that aren't integrated into the rest of
the library.

The third option is to just not save credentials at all, but load them
each time for each connection or new connection. This would probably be
the simplest, but will require a little more file io and such.

Does anyone have any suggestions on this? It would probably be good to
integrate this fix into the next version.

thanks

>>>------>

--

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

----- End forwarded message -----

>>>------>

--

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

Ed Schaller <schallee+postgres(at)darkmist(dot)net> writes:
> I am trying to connect to the database multiple times with different
> user accounts using kerberos. Unfortunately the current libpq libraries
> keep all of the kerberos credentials and such in static variables that
> are used for all subsequent connections.

Ugh.

> The options I am looking at are:

> Add it to the PGconn structure and pull it in where it is needed. This
> would require some api changes.

> Keep a hash of the usernames in static space and use the right
> credentials for the right user. This would fix the problem, but it would
> require extra data structures that aren't integrated into the rest of
> the library.

> The third option is to just not save credentials at all, but load them
> each time for each connection or new connection. This would probably be
> the simplest, but will require a little more file io and such.

I'm a bit confused here --- are the credentials used at all after
connection setup? If not, your third option seems good.

I'd still say that it sucks to be using static variables at all, even
during connection setup, since that will fail if someone tries to launch
two new connections concurrently. So the best bet would be to move the
variables into PGconn, even if they're not needed after startup.

I don't understand your statement that this'll require API changes.
PGconn is not an exported data structure.

regards, tom lane

> I'm a bit confused here --- are the credentials used at all after
> connection setup? If not, your third option seems good.

The credentials are not needed after the connection is set up.

> I'd still say that it sucks to be using static variables at all, even
> during connection setup, since that will fail if someone tries to launch
> two new connections concurrently. So the best bet would be to move the
> variables into PGconn, even if they're not needed after startup.

Yes, static variables like that cause lots of headaches. I'm trying to
use mod_auth_kerb to authenticate users and then use their credentials
to connect to the db. Works great with one user, but the next user who
gets that apache process is SOL.

> I don't understand your statement that this'll require API changes.
> PGconn is not an exported data structure.

The problems that I am running into is that conn is not available in
the functions it needs to be in. For example, fe_getauthname would need
the conn, but it is not available there, nor is it in conninfo_parse
where it is called from. We can pass the conn in for most of these, but
PQconndefaults doesn't have a conn at all and it calls conninfo_parse. I
am thinking that the solution is going to be number three on my list.

>>>------>

--

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

Ed Schaller <schallee+postgres(at)darkmist(dot)net> writes:
> The problems that I am running into is that conn is not available in
> the functions it needs to be in. For example, fe_getauthname would need
> the conn, but it is not available there, nor is it in conninfo_parse
> where it is called from. We can pass the conn in for most of these, but
> PQconndefaults doesn't have a conn at all and it calls conninfo_parse.

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.

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

regards, tom lane

> 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 |
+-------------+-----------------------+---------------+