Open item: kerberos warning message
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"
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]
2) Suppress the error message when called from this location. If
Kerberos is actually used, we'll get the error message again later and
show it then. [krberror_suppress.patch]
Thoughts?
//Magnus
Attachments:
krberror_remove.patchtext/x-diff; name=krberror_remove.patchDownload
*** a/src/interfaces/libpq/fe-auth.c
--- b/src/interfaces/libpq/fe-auth.c
***************
*** 190,217 **** pg_krb5_destroy(struct krb5_info * info)
}
-
- /*
- * pg_krb5_authname -- returns a copy of whatever name the user
- * has authenticated to the system, or NULL
- */
- static char *
- pg_krb5_authname(PQExpBuffer errorMessage)
- {
- char *tmp_name;
- struct krb5_info info;
-
- info.pg_krb5_initialised = 0;
-
- if (pg_krb5_init(errorMessage, &info) != STATUS_OK)
- return NULL;
- tmp_name = strdup(info.pg_krb5_name);
- pg_krb5_destroy(&info);
-
- return tmp_name;
- }
-
-
/*
* pg_krb5_sendauth -- client routine to send authentication information to
* the server
--- 190,195 ----
***************
*** 972,980 **** pg_fe_sendauth(AuthRequest areq, PGconn *conn)
char *
pg_fe_getauthname(PQExpBuffer errorMessage)
{
- #ifdef KRB5
- char *krb5_name = NULL;
- #endif
const char *name = NULL;
char *authn;
--- 950,955 ----
***************
*** 988,995 **** pg_fe_getauthname(PQExpBuffer errorMessage)
#endif
/*
! * pglock_thread() really only needs to be called around
! * pg_krb5_authname(), but some users are using configure
* --enable-thread-safety-force, so we might as well do the locking within
* our library to protect pqGetpwuid(). In fact, application developers
* can use getpwuid() in their application if they use the locking call we
--- 963,969 ----
#endif
/*
! * Some users are using configure
* --enable-thread-safety-force, so we might as well do the locking within
* our library to protect pqGetpwuid(). In fact, application developers
* can use getpwuid() in their application if they use the locking call we
***************
*** 998,1014 **** pg_fe_getauthname(PQExpBuffer errorMessage)
*/
pglock_thread();
- #ifdef KRB5
-
- /*
- * pg_krb5_authname gives us a strdup'd value that we need to free later,
- * however, we don't want to free 'name' directly in case it's *not* a
- * Kerberos login and we fall through to name = pw->pw_name;
- */
- krb5_name = pg_krb5_authname(errorMessage);
- name = krb5_name;
- #endif
-
if (!name)
{
#ifdef WIN32
--- 972,977 ----
***************
*** 1022,1033 **** pg_fe_getauthname(PQExpBuffer errorMessage)
authn = name ? strdup(name) : NULL;
- #ifdef KRB5
- /* Free the strdup'd string from pg_krb5_authname, if we got one */
- if (krb5_name)
- free(krb5_name);
- #endif
-
pgunlock_thread();
return authn;
--- 985,990 ----
krberror_suppress.patchtext/x-diff; name=krberror_suppress.patchDownload
*** a/src/interfaces/libpq/fe-auth.c
--- b/src/interfaces/libpq/fe-auth.c
***************
*** 124,130 **** struct krb5_info
static int
! pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info)
{
krb5_error_code retval;
--- 124,130 ----
static int
! pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info, bool seterrormessage)
{
krb5_error_code retval;
***************
*** 134,151 **** pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info)
retval = krb5_init_context(&(info->pg_krb5_context));
if (retval)
{
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_init_context: %s\n",
! error_message(retval));
return STATUS_ERROR;
}
retval = krb5_cc_default(info->pg_krb5_context, &(info->pg_krb5_ccache));
if (retval)
{
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_cc_default: %s\n",
! error_message(retval));
krb5_free_context(info->pg_krb5_context);
return STATUS_ERROR;
}
--- 134,153 ----
retval = krb5_init_context(&(info->pg_krb5_context));
if (retval)
{
! if (seterrormessage)
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_init_context: %s\n",
! error_message(retval));
return STATUS_ERROR;
}
retval = krb5_cc_default(info->pg_krb5_context, &(info->pg_krb5_ccache));
if (retval)
{
! if (seterrormessage)
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_cc_default: %s\n",
! error_message(retval));
krb5_free_context(info->pg_krb5_context);
return STATUS_ERROR;
}
***************
*** 154,162 **** pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info)
&(info->pg_krb5_client));
if (retval)
{
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_cc_get_principal: %s\n",
! error_message(retval));
krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
krb5_free_context(info->pg_krb5_context);
return STATUS_ERROR;
--- 156,165 ----
&(info->pg_krb5_client));
if (retval)
{
! if (seterrormessage)
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_cc_get_principal: %s\n",
! error_message(retval));
krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
krb5_free_context(info->pg_krb5_context);
return STATUS_ERROR;
***************
*** 165,173 **** pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info)
retval = krb5_unparse_name(info->pg_krb5_context, info->pg_krb5_client, &(info->pg_krb5_name));
if (retval)
{
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_unparse_name: %s\n",
! error_message(retval));
krb5_free_principal(info->pg_krb5_context, info->pg_krb5_client);
krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
krb5_free_context(info->pg_krb5_context);
--- 168,177 ----
retval = krb5_unparse_name(info->pg_krb5_context, info->pg_krb5_client, &(info->pg_krb5_name));
if (retval)
{
! if (seterrormessage)
! printfPQExpBuffer(errorMessage,
! "pg_krb5_init: krb5_unparse_name: %s\n",
! error_message(retval));
krb5_free_principal(info->pg_krb5_context, info->pg_krb5_client);
krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
krb5_free_context(info->pg_krb5_context);
***************
*** 203,209 **** pg_krb5_authname(PQExpBuffer errorMessage)
info.pg_krb5_initialised = 0;
! if (pg_krb5_init(errorMessage, &info) != STATUS_OK)
return NULL;
tmp_name = strdup(info.pg_krb5_name);
pg_krb5_destroy(&info);
--- 207,213 ----
info.pg_krb5_initialised = 0;
! if (pg_krb5_init(errorMessage, &info, false) != STATUS_OK)
return NULL;
tmp_name = strdup(info.pg_krb5_name);
pg_krb5_destroy(&info);
***************
*** 235,241 **** pg_krb5_sendauth(PGconn *conn)
return STATUS_ERROR;
}
! ret = pg_krb5_init(&conn->errorMessage, &info);
if (ret != STATUS_OK)
return ret;
--- 239,245 ----
return STATUS_ERROR;
}
! ret = pg_krb5_init(&conn->errorMessage, &info, true);
if (ret != STATUS_OK)
return ret;
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:
Show quoted text
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
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
Show quoted text
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's
PostgreSQL training!