On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:

* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
What the krb5 method does is IMO a documented bug. The realm name is part
of the name.

As I explained at some length you cannot assume the username (first
component of the principal) has any meaning by itself, except in small
deployments with no external trust agreements.  Kerberos (and AD) are
designed to support larger infrastructures with multiple organizations.

This isn't unexpected for PG as the current krb5 support does this. I'm not a big fan of it but at the same time I don't feel it's justification to drop it from 8.3. Having it only allow the default realm would be an
option which could work in 8.3, imv.

I don't think the fact that the existing krb5 code does the wrong thing (and can't be used in an environment with cross-realm agreements) is justification for doing the wrong thing in a new capability. The code in my original patch would do the latter (default realm only).

More precisely: if you do a gss_import_name() on "smith" and "[EMAIL PROTECTED]" you get the same internal representation, and gss_compare_name() will tell you they're the same. Also gss_compare_name() will tell you "[EMAIL PROTECTED]" is different from either of the first two.

If we don't use gss_compare_name(), or some similar mechanism, to compare connection names to PG usernames, then I don't think GSSAPI support should be included in 8.3.

Longer term (since it's likely too
late to be accepted now), as I think has been discussed in the past, PG could really use a .k5login-esque, either admin-only (ala pg_hba.conf / ident map) or per-user (some sort of ALTER ROLE that a user could do on
himself?), mapping functionality.

There has been discussion of a general mapping layer between authentication names and authorization/role names. I think that's the way to go. I haven't thought about who or where the administration of the mapping ought to be.

See note about authentication vs authorization in last email.

It doesn't strike me as terribly complex or hard to do but it certainly
goes beyond the what is currently implemented for GSS in 8.3, and what
exists currently for krb5.  It's also something which could,
technically, be added later.  I do think it would be better done now
though, if possible, since otherwise we would have to default to the
current sub-par behaviour for quite some time (if not forever).



The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to