On Fri, Apr 8, 2016 at 1:38 PM, Magnus Hagander wrote:
> On Tue, Mar 29, 2016 at 11:24 PM, Christian Ullrich
> wrote:
>
>> * Magnus Hagander wrote:
>>
>> On Tue, Mar 29, 2016 at 5:09 PM, David Steele
>>> wrote:
>>>
>>
>> It seems like this patch should be set "ready for committer". Can one of
On Tue, Mar 29, 2016 at 11:24 PM, Christian Ullrich
wrote:
> * Magnus Hagander wrote:
>
> On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
>>
>
> It seems like this patch should be set "ready for committer". Can one of
>>> the reviewers do that if appropriate?
>>>
>>
>> I'll pick it up to d
On Apr 8, 2016 1:13 AM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Apr 7, 2016 9:14 PM, "Christian Ullrich"
wrote:
> >> Magnus, do you intend to commit the patch before the feature freeze?
>
> > It's on my list of things to work on this weekend, yeah.
>
> But the stated feature freeze
Magnus Hagander writes:
> On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>> Magnus, do you intend to commit the patch before the feature freeze?
> It's on my list of things to work on this weekend, yeah.
But the stated feature freeze deadline is tomorrow (Friday), not the
weekend or later.
On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>
> * Magnus Hagander wrote:
>
>> On Tue, Mar 29, 2016 at 5:09 PM, David Steele
wrote:
>
>
>>> It seems like this patch should be set "ready for committer". Can one
of
>>> the reviewers do that if appropriate?
>
>
>> I'll pick it up to do that a
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Magnus, do you intend to commit the patch be
Alvaro Herrera writes:
> Tom Lane wrote:
>> Anyway, as things stand, elog(ERROR) will abort the session safely but
>> you won't necessarily get the kind of logging you want, so expected
>> auth-failure cases should try to go the STATUS_ERROR route.
> In other words, the use of palloc() and friend
Tom Lane wrote:
> Alvaro Herrera writes:
> > So, it seems that ClientAuthentication() expects to raise ereport(FATAL)
> > in case of authentication failures. But what's the code path that
> > causes that to happen if a ereport(ERROR) happens in there? Because all
> > that code is pretty careful
Alvaro Herrera writes:
> So, it seems that ClientAuthentication() expects to raise ereport(FATAL)
> in case of authentication failures. But what's the code path that
> causes that to happen if a ereport(ERROR) happens in there? Because all
> that code is pretty careful to not do ereport(ERROR) d
So, it seems that ClientAuthentication() expects to raise ereport(FATAL)
in case of authentication failures. But what's the code path that
causes that to happen if a ereport(ERROR) happens in there? Because all
that code is pretty careful to not do ereport(ERROR) directly and
instead return STATU
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Ah, good news!
I hope it's not coming too la
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
> On 3/24/16 5:22 PM, Alvaro Herrera wrote:
>
>> Christian Ullrich wrote:
>>
>> To be honest, I'm not sure what can and cannot be done in auth code. I
>>> took inspiration from the existing SSPI code and nearly every error
>>> check in pg_SSPI_
On 3/24/16 5:22 PM, Alvaro Herrera wrote:
Christian Ullrich wrote:
To be honest, I'm not sure what can and cannot be done in auth code. I
took inspiration from the existing SSPI code and nearly every error
check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already,
directly or via pg_SSPI
Christian Ullrich wrote:
> To be honest, I'm not sure what can and cannot be done in auth code. I
> took inspiration from the existing SSPI code and nearly every error
> check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already,
> directly or via pg_SSPI_error(). If this could cause serious
* From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Christian Ullrich wrote:
> > * Christian Ullrich wrote:
> >
> > >* From: Magnus Hagander [mailto:mag...@hagander.net]
>
> > >>Code uses a mix of malloc() and palloc() (through sprintf). Is there
> > >>a reason for that?
> > >
> > >I wasn
Christian Ullrich wrote:
> * Christian Ullrich wrote:
>
> >* From: Magnus Hagander [mailto:mag...@hagander.net]
> >>Code uses a mix of malloc() and palloc() (through sprintf). Is there a
> >>reason for that?
> >
> >I wasn't sure which to prefer, so I looked around in auth.c, and other than
> >RAD
Christian Ullrich writes:
> Updated patch attached.
Okay, I am happy now. Thanks!
signature.asc
Description: PGP signature
* From: Christian Ullrich
> * From: Robbie Harwood [mailto:rharw...@redhat.com]
>
> > Christian Ullrich writes:
> > > + /* Replace domainname with realm name. */
> > > + if (upnamerealmsize > domainnamesize)
> > > + {
> > > + pfree(upname);
> > > +
On 2016-03-24 16:35, Christian Ullrich wrote:
* From: Robbie Harwood [mailto:rharw...@redhat.com]
Christian Ullrich writes:
pg_SSPI_recvauth(Port *port)
{
int mtype;
+ int status;
The section of this function for include_realm c
* From: Robbie Harwood [mailto:rharw...@redhat.com]
> Christian Ullrich writes:
>
> > Updated patch attached.
>
> I unfortunately don't have windows machines to test this on, but I
> thought it might be helpful to review this anyway since I'm touching
> code in the same general area (GSSAPI).
On Thu, Mar 24, 2016 at 11:07 AM, Robbie Harwood wrote:
> Christian Ullrich writes:
>
>> Updated patch attached.
>
> I unfortunately don't have windows machines to test this on, but I
> thought it might be helpful to review this anyway since I'm touching
> code in the same general area (GSSAPI).
Christian Ullrich writes:
> Updated patch attached.
I unfortunately don't have windows machines to test this on, but I
thought it might be helpful to review this anyway since I'm touching
code in the same general area (GSSAPI). And as far as I can tell, you
don't break anything there; master co
* Christian Ullrich wrote:
* From: Magnus Hagander [mailto:mag...@hagander.net]
I don't like the name "real_realm" as a parameter name. I'm wondering if
it might be better to reverse the meaning, and call it sspi_netbios_realm
(and then change the default to on, to be backwards compatible).
* From: Magnus Hagander [mailto:mag...@hagander.net]
> I took a quick look at this one, and have some initial thoughts.
>
> I don't like the name "real_realm" as a parameter name. I'm wondering if
> it might be better to reverse the meaning, and call it sspi_netbios_realm
> (and then change the d
On Fri, Jan 15, 2016 at 9:46 PM, Christian Ullrich
wrote:
> * Christian Ullrich wrote:
>
> * Christian Ullrich wrote:
>>
>> * Christian Ullrich wrote:
>>>
>>> > According to the release notes, the default for the "include_realm"
>>> > option in SSPI authentication was changed from off to on in 9.
* Christian Ullrich wrote:
* Christian Ullrich wrote:
* Christian Ullrich wrote:
> According to the release notes, the default for the "include_realm"
> option in SSPI authentication was changed from off to on in 9.5 for
> > improved security. However, the authenticated user name, with the
* Christian Ullrich wrote:
* Christian Ullrich wrote:
> According to the release notes, the default for the "include_realm"
> option in SSPI authentication was changed from off to on in 9.5 for
> > improved security. However, the authenticated user name, with the
> > option enabled, includes t
27 matches
Mail list logo