Henry B. Hotz 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. >> >> Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM that >> you set in the config file be more flexible? In that it actually allows >> scenarios like server/resource domains (not sure how common they are in >> unix krb setups, but they're certainly not unfamiliar in the Windows AD >> world)? > > Yes and no. It certainly would have made it easier to test my original > patch since the server was in a test realm and I couldn't use my normal > production identity. I'd imagine deployments where the users are in a > different realm from the servers are somewhat common.
Yes, that is the "resource domain" model that at least MS suggested you use earlier on - they may still do so. > The counter is that (if done naively) it would prevent you from > supporting users from multiple realms at all. I never completely tested > this, but I think with my original patch you could define both "smith" > (== "[EMAIL PROTECTED]") and "[EMAIL PROTECTED]" as users to PG. They > wouldn't be the same user (which you might want), but you could support > both of them. Well, you could turn it off, and use those usernames then, no? > Is there any (other) code in PG that would barf on long usernames that > contain "@" and/or "."? I don't think there is any risk with it containing that, but there is a max length of a username somewhere of course... >>> 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. >> >> I think that's a horrible idea, given that it works perfectly fine the >> way >> it is now for the vast majority of users. >> >> That said, we should certainly fix it in one way or another for 8.3. >> But if >> that fails, I see no reason at all to pull the feature. > > If this isn't fixed then PG will never be a supported infrastructure > service at JPL the way MySQL currently is. I had hoped to use the > GSSAPI support as a feature to pry some people away from MySQL, but > without the ability to integrate into a multi-realm infrastructure this > won't fly. Of course even with proper support it still may never > happen, so that isn't a threat. Sure, but that's no reason to pull it from 8.3 if it can only be fixed in 8.4. It's a good reason to work towards having it fixed in 8.3, certainly, but not a reason to pull it if it isn't there. FWIW, I'm fairly certain I can have a match_realm parameter done for beta3. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster