Re: Spurious Kerberos error messages

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spurious Kerberos error messages
Date: 2008-11-09 16:54:38
Message-ID: 491715CE.2000604@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-09 17:03:15 Re: Spurious Kerberos error messages
Previous Message Tom Lane 2008-11-09 16:02:32 Re: Block-level CRC checks