Re: 8.3 GSS Issues
От | Henry B. Hotz |
---|---|
Тема | Re: 8.3 GSS Issues |
Дата | |
Msg-id | AD5AA391-53A1-4743-8EBC-B551BE6BCAB9@jpl.nasa.gov обсуждение исходный текст |
Ответ на | Re: 8.3 GSS Issues (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: 8.3 GSS Issues
(Magnus Hagander <magnus@hagander.net>)
|
Список | pgsql-hackers |
On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote: > * Henry B. Hotz (hotz@jpl.nasa.gov) 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 "smith@DEFAULT.REALM" you get the same internal representation, and gss_compare_name() will tell you they're the same. Also gss_compare_name() will tell you "smith@OTHER.REALM" 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). > > Thanks, > > Stephen ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
В списке pgsql-hackers по дате отправления: