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