Including kerberos realm
Here's the patch allowing for the parameter include_realm on
pg_hba.conf, that makes the authentication system pass the user@realm
format username to the identmap, instead of stripping the realm. This
was the original reason for having regexp support in the ident maps..
The idea is to make it a lot easier to run with multiple kerberos realms
in the same installation. Hello Stephen :-)
Comments?
//Magnus
Attachments:
include_realm.patchtext/x-diff; name=include_realm.patchDownload+68-30
Magnus Hagander wrote:
Here's the patch allowing for the parameter include_realm on
pg_hba.conf, that makes the authentication system pass the user@realm
format username to the identmap, instead of stripping the realm.
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Magnus Hagander wrote:
Here's the patch allowing for the parameter include_realm on
pg_hba.conf, that makes the authentication system pass the user@realm
format username to the identmap, instead of stripping the realm.Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?
I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically not have very many different lines in pg_hba for
this, and just duplicating the parameter there would be ok I think.
I'd rather move more of the krb parameters to be *just* in pg_hba.conf,
but for now I left those in postgresql.conf as fallbacks..
//Magnus
Magnus Hagander <magnus@hagander.net> writes:
Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?
I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically not have very many different lines in pg_hba for
this, and just duplicating the parameter there would be ok I think.
I'd rather move more of the krb parameters to be *just* in pg_hba.conf,
but for now I left those in postgresql.conf as fallbacks..
If you think those parameters would make more sense in pg_hba.conf,
let's just move them and be done with it. There has never been any
intention that administrator-only GUCs would be promised compatible
across versions. And the GUC mechanism is really rather a lot of
overhead compared to options on a pg_hba line ...
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically not have very many different lines in pg_hba for
this, and just duplicating the parameter there would be ok I think.I'd rather move more of the krb parameters to be *just* in pg_hba.conf,
but for now I left those in postgresql.conf as fallbacks..If you think those parameters would make more sense in pg_hba.conf,
let's just move them and be done with it. There has never been any
intention that administrator-only GUCs would be promised compatible
across versions. And the GUC mechanism is really rather a lot of
overhead compared to options on a pg_hba line ...
Well, it does make sense to have defaults in postgresql.conf - but I
don't think it's worth the overhead.
I'll commit the stuff I have for now and put it on my TODO to remove
them completely from postgresql.conf later. I'll see if I have time to
get it done for 8.4.
//Magnus
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically not have very many different lines in pg_hba for
this, and just duplicating the parameter there would be ok I think.
I'd rather move more of the krb parameters to be *just* in pg_hba.conf,
but for now I left those in postgresql.conf as fallbacks..If you think those parameters would make more sense in pg_hba.conf,
let's just move them and be done with it. There has never been any
intention that administrator-only GUCs would be promised compatible
across versions. And the GUC mechanism is really rather a lot of
overhead compared to options on a pg_hba line ...Well, it does make sense to have defaults in postgresql.conf - but I
don't think it's worth the overhead.I'll commit the stuff I have for now and put it on my TODO to remove
them completely from postgresql.conf later. I'll see if I have time to
get it done for 8.4.
Ok, I've applied a patch for this for the parameter krb_realm and
krb_server_hostname, which are the ones that currently supported both.
Should we also consider moving the remaining ones there?
(krb_server_keyfile, krb_srvname, krb_caseinsens_users)
They do make sense to set on a per-server basis, on the other hand they
are the only remaining authentication-method-specific parameters left...
//Magnus
Magnus Hagander wrote:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?I thought about that, but I don't want to add extra gucs without a good
reason. You'd typically not have very many different lines in pg_hba for
this, and just duplicating the parameter there would be ok I think.
I'd rather move more of the krb parameters to be *just* in pg_hba.conf,
but for now I left those in postgresql.conf as fallbacks..If you think those parameters would make more sense in pg_hba.conf,
let's just move them and be done with it. There has never been any
intention that administrator-only GUCs would be promised compatible
across versions. And the GUC mechanism is really rather a lot of
overhead compared to options on a pg_hba line ...Well, it does make sense to have defaults in postgresql.conf - but I
don't think it's worth the overhead.I'll commit the stuff I have for now and put it on my TODO to remove
them completely from postgresql.conf later. I'll see if I have time to
get it done for 8.4.Ok, I've applied a patch for this for the parameter krb_realm and
krb_server_hostname, which are the ones that currently supported both.Should we also consider moving the remaining ones there?
(krb_server_keyfile, krb_srvname, krb_caseinsens_users)They do make sense to set on a per-server basis, on the other hand they
are the only remaining authentication-method-specific parameters left...
If they make more sense in postgresql.conf, I would just leave them
there.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +