Re: 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
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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