Thread: 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@darkmist.net | mistymushroom | +-------------+-----------------------+---------------+ ----- End forwarded message ----- >>>------> -- +-------------+-----------------------+---------------+ | Ed Schaller | schallee@darkmist.net | mistymushroom | +-------------+-----------------------+---------------+
Ed Schaller <schallee+postgres@darkmist.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@darkmist.net | mistymushroom | +-------------+-----------------------+---------------+
Ed Schaller <schallee+postgres@darkmist.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@darkmist.net | mistymushroom | +-------------+-----------------------+---------------+