Thread: Spurious Kerberos error messages
I get the following display now when I connect to a non-running server, all default settings: psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found could not connect to server: No such file or directory Is the server running locally and accepting connectionson Unix domain socket "/tmp/.s.PGSQL.5432"?
Peter Eisentraut <peter_e@gmx.net> writes: > I get the following display now when I connect to a non-running server, > all default settings: > psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found > could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket "/tmp/.s.PGSQL.5432"? Hmm ... a few of the buildfarm machines have failed like that too in recent days, but it's inconsistent (only one or two of the regression tests fail that way, typically). Does yours fail always? regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> I get the following display now when I connect to a non-running server, >> all default settings: > >> psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found >> could not connect to server: No such file or directory >> Is the server running locally and accepting >> connections on Unix domain socket "/tmp/.s.PGSQL.5432"? > > Hmm ... a few of the buildfarm machines have failed like that too in > recent days, but it's inconsistent (only one or two of the regression > tests fail that way, typically). Does yours fail always? Nothing has changed about when it fails, only the extra krb error message before the usual error messages (could not connect, server is starting up) are new. This probably has something to do with Magnus's work on concatenating rather than hiding error messages across multiple passes. I see this on Mac and Linux, so it should be reproducible with any Kerberos-enabled build.
Peter Eisentraut <peter_e@gmx.net> writes: > Nothing has changed about when it fails, only the extra krb error > message before the usual error messages (could not connect, server is > starting up) are new. This probably has something to do with Magnus's > work on concatenating rather than hiding error messages across multiple > passes. > I see this on Mac and Linux, so it should be reproducible with any > Kerberos-enabled build. Ah ... I had to try it on a machine *without* a credentials cache to see something funny ;-) What's happening is that pg_fe_getauthname -> pg_krb5_authname -> pg_krb5_init fails and sets an error message in conn->errorMessage, which we don't care about because we will get the username from pqGetpwuid if Kerberos can't help us. But because of the concatenation change, this gets added onto the (unrelated) later failure message. I'm tempted to say that this code path simply shouldn't be setting errorMessage at all. Alternatively we could have pg_fe_getauthname clear out errorMessage upon successfully fetching a non-Kerberized username ... but that would lose anything previously put into errorMessage. (In which connection it seems like a bad thing that pg_krb5_init uses printfPQExpBuffer rather than appendPQExpBuffer.) Thoughts? regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> Nothing has changed about when it fails, only the extra krb error >> message before the usual error messages (could not connect, server is >> starting up) are new. This probably has something to do with Magnus's >> work on concatenating rather than hiding error messages across multiple >> passes. > >> I see this on Mac and Linux, so it should be reproducible with any >> Kerberos-enabled build. > > Ah ... I had to try it on a machine *without* a credentials cache to > see something funny ;-) > > What's happening is that pg_fe_getauthname -> pg_krb5_authname -> > pg_krb5_init fails and sets an error message in conn->errorMessage, > which we don't care about because we will get the username from > pqGetpwuid if Kerberos can't help us. But because of the concatenation > change, this gets added onto the (unrelated) later failure message. > > I'm tempted to say that this code path simply shouldn't be setting > errorMessage at all. Alternatively we could have pg_fe_getauthname > clear out errorMessage upon successfully fetching a non-Kerberized > username ... but that would lose anything previously put into > errorMessage. (In which connection it seems like a bad thing that > pg_krb5_init uses printfPQExpBuffer rather than appendPQExpBuffer.) > > Thoughts? Another option would be not to call the kerberos code there at all. All other authentication methods that take the userid externally (gssapi, sspi, ident) require the user to specify the name to connect as if it's different from the one in the operating system. I think that's a very uncommon scenario in any case - almost everybody will be using whatever userid is used in the system, when using Kerberos. //Magnus
Magnus Hagander <magnus@hagander.net> writes: > Another option would be not to call the kerberos code there at all. All > other authentication methods that take the userid externally (gssapi, > sspi, ident) require the user to specify the name to connect as if it's > different from the one in the operating system. I think that's a very > uncommon scenario in any case - almost everybody will be using whatever > userid is used in the system, when using Kerberos. Hmm, that's an interesting alternative. I like it because it takes away some useless connection-startup overhead in the common case where you're using a Kerberos-enabled library but Kerberos isn't set up on the system. Another possible argument in favor is that it's bogus to ask Kerberos for the username unless the actual auth method is Kerberos --- which is something libpq can't know at that point. OTOH, that code was put in deliberately. It might be a good idea to troll the archives and see if we can find out the rationale for it. regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Another option would be not to call the kerberos code there at all. All >> other authentication methods that take the userid externally (gssapi, >> sspi, ident) require the user to specify the name to connect as if it's >> different from the one in the operating system. I think that's a very >> uncommon scenario in any case - almost everybody will be using whatever >> userid is used in the system, when using Kerberos. > > Hmm, that's an interesting alternative. I like it because it takes away > some useless connection-startup overhead in the common case where you're > using a Kerberos-enabled library but Kerberos isn't set up on the system. > Another possible argument in favor is that it's bogus to ask Kerberos > for the username unless the actual auth method is Kerberos --- which is > something libpq can't know at that point. Yeah, that's my thought as well. > OTOH, that code was put in deliberately. It might be a good idea to > troll the archives and see if we can find out the rationale for it. AFAICS, it's been there since before our CVS history started... Not exactly in the same form, but the call to pg_krb5_authname was in fe_getauthname... //Magnus
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > >> Another option would be not to call the kerberos code there at all. All >> other authentication methods that take the userid externally (gssapi, >> sspi, ident) require the user to specify the name to connect as if it's >> different from the one in the operating system. I think that's a very >> uncommon scenario in any case - almost everybody will be using whatever >> userid is used in the system, when using Kerberos. >> > > Hmm, that's an interesting alternative. I like it because it takes away > some useless connection-startup overhead in the common case where you're > using a Kerberos-enabled library but Kerberos isn't set up on the system. > > +1. Anything that reduces connection overhead is a definite plus. cheers andrew