From: | "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.3 GSS Issues |
Date: | 2007-10-28 04:46:10 |
Message-ID: | 4909D006-6674-498C-882B-78BBC3420EF9@jpl.nasa.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 27, 2007, at 1:36 AM, Magnus Hagander wrote:
>> 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.
A brief inspection suggests the relevant code from my original patch
would work with very little modification. It supports what I need to
support.
*I* have no need for a "match_realm" parameter as long as realm
matching *is* done and can be done on a per-user basis. Obviously it
would be convenient for some other people if realm matching could be
disabled or a non-default realm could be made the default and
required. I just don't want such "extras" to create security holes
(by equating different users) or prevent support of the full user pool.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu
From | Date | Subject | |
---|---|---|---|
Next Message | sayali k | 2007-10-28 04:48:13 | Re: Definition of function base_yylex in version 8.1.4 |
Previous Message | J. Andrew Rogers | 2007-10-28 04:38:11 | Re: Opportunity for a Radical Changes in Database Software |