Open item: kerberos warning message

Magnus Hagander <magnus@hagander.net> writes:

The reason this is happening is that we are initializing Kerberos even
if we're not going to use it. The reason for doing *this*, is that if
kerberos is compiled in, we use it to find out if we should try a
different username than the one logged in to the local system - we look
at the kerberos login.

We don't do this for any other login, including kerberos over GSSAPI.
AFAIK, we've heard no complaints.

I see two ways to fix this, and have attached two patches:

1) Remove the support for getting this username. AFAIK, it's not even
documented. [krberror_remove.patch]

+1 for this approach.

regards, tom lane

Magnus, et al,

* Magnus Hagander (magnus@hagander.net) wrote:

Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user "mha"
psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found
FATAL: password authentication failed for user "mha"

That is annoying, I can understand that.

The reason this is happening is that we are initializing Kerberos even
if we're not going to use it. The reason for doing *this*, is that if
kerberos is compiled in, we use it to find out if we should try a
different username than the one logged in to the local system - we look
at the kerberos login.

This made sense before we had mappings support because the only user you
could possibly be in PG is the one you authenticated as.

We don't do this for any other login, including kerberos over GSSAPI.
AFAIK, we've heard no complaints.

Well, I havn't moved all my systems to GSSAPI yet.. :)

Thoughts?

Now that we have support for mappings, I expect it will be more common
for a user to authenticate with princ 'A' and then connect using their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use -U (or equiv) if necessary.

Thanks,

Stephen

For what it's worth this always bothered me. I often - but nit always
- - have kerberos tickets gsstark@... lying around but my unix id is
stark.

I never set up kerberos authentication for postgres but whrn the
tickets happen to be there it fails to authenticate. I think I
complained about this in the past but I don't recall - it would have
been a long time ago.

--
Greg

On 8 Jan 2009, at 11:22, Stephen Frost <sfrost@snowman.net> wrote:

Stephen Frost wrote:

Magnus, et al,

* Magnus Hagander (magnus@hagander.net) wrote:

Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user "mha"
psql: pg_krb5_init: krb5_cc_get_principal: No credentials cache found
FATAL: password authentication failed for user "mha"

That is annoying, I can understand that.

The reason this is happening is that we are initializing Kerberos even
if we're not going to use it. The reason for doing *this*, is that if
kerberos is compiled in, we use it to find out if we should try a
different username than the one logged in to the local system - we look
at the kerberos login.

This made sense before we had mappings support because the only user you
could possibly be in PG is the one you authenticated as.

We don't do this for any other login, including kerberos over GSSAPI.
AFAIK, we've heard no complaints.

Well, I havn't moved all my systems to GSSAPI yet.. :)

Thoughts?

Now that we have support for mappings, I expect it will be more common
for a user to authenticate with princ 'A' and then connect using their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use -U (or equiv) if necessary.

I have applied this version of the patch.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

Now that we have support for mappings, I expect it will be more common
for a user to authenticate with princ 'A' and then connect using their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use -U (or equiv) if necessary.

I have applied this version of the patch.

yay!

Incidentally, this will have to be in the update notes I think.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

On 13 jan 2009, at 15.20, Gregory Stark <stark@enterprisedb.com> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Now that we have support for mappings, I expect it will be more
common
for a user to authenticate with princ 'A' and then connect using
their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use -U (or equiv) if necessary.

I have applied this version of the patch.

yay!

Incidentally, this will have to be in the update notes I think.

There are a number of changes around the auth methods and pg_hba in
8.4, that we need to carefully note.

/Magnus