On 05/28/2013 04:04 PM, Amit Langote wrote:
> On Tue, May 28, 2013 at 2:32 PM, Craig Ringer wrote:
>> On 05/11/2013 03:25 AM, Robert Haas wrote:
>>> Not really. We could potentially fix it by extending the wire
>>> protocol to allow the server to respond to the client's startup packet
>>> with a
On Tue, May 28, 2013 at 01:32:53PM +0800, Craig Ringer wrote:
> On 05/11/2013 03:25 AM, Robert Haas wrote:
> > Not really. We could potentially fix it by extending the wire
> > protocol to allow the server to respond to the client's startup packet
> > with a further challenge, and extend libpq to
On Tue, May 28, 2013 at 5:04 PM, Amit Langote wrote:
> On Tue, May 28, 2013 at 2:32 PM, Craig Ringer wrote:
>> On 05/11/2013 03:25 AM, Robert Haas wrote:
>>> Not really. We could potentially fix it by extending the wire
>>> protocol to allow the server to respond to the client's startup packet
>
On Tue, May 28, 2013 at 2:32 PM, Craig Ringer wrote:
> On 05/11/2013 03:25 AM, Robert Haas wrote:
>> Not really. We could potentially fix it by extending the wire
>> protocol to allow the server to respond to the client's startup packet
>> with a further challenge, and extend libpq to report that
On Tue, May 28, 2013 at 01:32:53PM +0800, Craig Ringer wrote:
> On 05/11/2013 03:25 AM, Robert Haas wrote:
> > Not really. We could potentially fix it by extending the wire
> > protocol to allow the server to respond to the client's startup packet
> > with a further challenge, and extend libpq to
On 5/27/13, Craig Ringer wrote:
> We were just talking about "things we'd like to do in wire protocol 4".
>
> Allowing multi-stage authentication has come up repeatedly and should
> perhaps go on that list. The most obvious case being "ident auth failed,
> demand md5".
I'd like to use LDAP with
On 05/11/2013 03:25 AM, Robert Haas wrote:
> Not really. We could potentially fix it by extending the wire
> protocol to allow the server to respond to the client's startup packet
> with a further challenge, and extend libpq to report that challenge
> back to the user and allow sending a response.
Langote
Date: Fri, May 17, 2013 at 1:29 AM
Subject: Re: [HACKERS] Logging of PAM Authentication Failure
To: Tom Lane
Cc: Andres Freund , Kyotaro HORIGUCHI
, Kyotaro HORIGUCHI
, Robert Haas
, PostgreSQL-development
On Fri, May 17, 2013 at 1:05 AM, Tom Lane wrote:
> Amit Langote writes:
&g
On Thu, May 16, 2013 at 7:01 AM, Andres Freund wrote:
> I unfortunately have to say I don't really see the point of this. The
> cost of the additional connection attempt is rather low and we have to
> deal with the superflous attempts anyway since there will be old libpqs
> around for years. Why i
On Fri, May 17, 2013 at 1:46 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-05-17 01:29:25 +0900, Amit Langote wrote:
>>> Can this stay in the future releases for new users of libpq to
>>> consider using it (saving them a reconnection, however small a benefit
>>> that is) or at least psql
Andres Freund writes:
> On 2013-05-17 01:29:25 +0900, Amit Langote wrote:
>> Can this stay in the future releases for new users of libpq to
>> consider using it (saving them a reconnection, however small a benefit
>> that is) or at least psql which is being changed to use it anyway? I
>> only thin
On 2013-05-17 01:29:25 +0900, Amit Langote wrote:
> On Fri, May 17, 2013 at 1:05 AM, Tom Lane wrote:
> > Amit Langote writes:
> >> On Thu, May 16, 2013 at 8:01 PM, Andres Freund
> >> wrote:
> >>> I unfortunately have to say I don't really see the point of this. The
> >>> cost of the additional
On Fri, May 17, 2013 at 1:05 AM, Tom Lane wrote:
> Amit Langote writes:
>> On Thu, May 16, 2013 at 8:01 PM, Andres Freund
>> wrote:
>>> I unfortunately have to say I don't really see the point of this. The
>>> cost of the additional connection attempt is rather low and we have to
>>> deal with
Amit Langote writes:
> On Thu, May 16, 2013 at 8:01 PM, Andres Freund wrote:
>> I unfortunately have to say I don't really see the point of this. The
>> cost of the additional connection attempt is rather low and we have to
>> deal with the superflous attempts anyway since there will be old libpq
On Thu, May 16, 2013 at 8:01 PM, Andres Freund wrote:
> On 2013-05-16 17:35:10 +0900, Amit Langote wrote:
>> On Thu, May 16, 2013 at 3:53 PM, Amit Langote
>> wrote:
>> > Attached herewith is a patch based on description in my previous mail.
>> > This patch would need revision since the error sit
On 2013-05-16 17:35:10 +0900, Amit Langote wrote:
> On Thu, May 16, 2013 at 3:53 PM, Amit Langote wrote:
> > Attached herewith is a patch based on description in my previous mail.
> > This patch would need revision since the error situation in case of
> > authentication timeout on the server needs
On Thu, May 16, 2013 at 3:53 PM, Amit Langote wrote:
> Attached herewith is a patch based on description in my previous mail.
> This patch would need revision since the error situation in case of
> authentication timeout on the server needs to be handled; probably in
> simple_prompt()?
Forgot att
Attached herewith is a patch based on description in my previous mail.
This patch would need revision since the error situation in case of
authentication timeout on the server needs to be handled; probably in
simple_prompt()?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Sorry that I am writing separate emails on the same topic.
I seem to have a solution that allows us to accomplish what we are
trying to without much change to the existing libpq interface
(especially what to expect about return values and connection state
that we are in when we return from connectD
>>> I created a patch which enables it to use the existing connection in
>>> such a case (unlike what we currently do). It modifies
>>> connectDBComplete() and PQconnectPoll() to also include states
>>> pertaining to password being accepted from the user. That is, the
>>> state machine in PQconnect
On Wed, May 15, 2013 at 11:04 PM, Kyotaro HORIGUCHI
wrote:
>> Is it right that it is only in the case a password prompt is needed
>> that a new connection is created after dropping the just-failed
>> connection?
>
> It's quite doubtful.\:-p The sequense seems fragile to say the
> least. Inserting
> Is it right that it is only in the case a password prompt is needed
> that a new connection is created after dropping the just-failed
> connection?
It's quite doubtful.\:-p The sequense seems fragile to say the
least. Inserting password request state into the client-side state
machine looks quit
> Please add patches here so they don't get forgotten:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Do we really need to add *2* new libpq functions just to support this?
I will add the patches to commitfest after reviewing it a bit to see
if we can do away without having
On Tue, May 14, 2013 at 11:20 AM, Amit Langote wrote:
> Hello,
>
> Is it right that it is only in the case a password prompt is needed
> that a new connection is created after dropping the just-failed
> connection?
> I created a patch which enables it to use the existing connection in
> such a cas
Hello,
Is it right that it is only in the case a password prompt is needed
that a new connection is created after dropping the just-failed
connection?
I created a patch which enables it to use the existing connection in
such a case (unlike what we currently do). It modifies
connectDBComplete() and
> Well, if we are allowed to use a bit ugry way, the attached patch
> seems to cope with this issue. As far as I can see there's no
> problem since pg_fe_sendauth() refueses to send empty password.
>
> Any suggestions?
That seems to do the trick. This probably solves the problem that I
originally
> In fact, this is the behavior with all the authentication methods that
> require a password. But, it is only in the case of PAM authentication
> that auth_failed() logs error when first connection attempt is made
> (without password), since the STATUS_EOF is not passed to it in that
> case.
Well
> This code seems to me expecting for psql to send password without
> closing current connnection.On the other hand psql does as
> follows.
>
> bin/psql/startup.c: 227
>>pset.db = PQconnectdbParams(keywords, values, true);
>>free(keywords);
>>free(values);
>>
>>if (PQstatus(pset.db)
Hello,
> > auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
> > STATUS_EOF status (ie, client closed the connection without responding).
> > But it looks like the PAM code path doesn't have a way to return that
> > status code, even when pam_passwd_conv_proc() knows that th
> auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
> STATUS_EOF status (ie, client closed the connection without responding).
> But it looks like the PAM code path doesn't have a way to return that
> status code, even when pam_passwd_conv_proc() knows that that's what
> happ
Robert Haas writes:
> On Wed, May 8, 2013 at 10:40 PM, Amit Langote wrote:
>> I tried to observe the behavior with md5 method (without -W) and
>> observed that no authentication failure is logged, since server
>> probably behaves differently in response to the psql's first
>> connection request i
On Wed, May 8, 2013 at 10:40 PM, Amit Langote wrote:
> When client authentication method is set to "pam" in pg_hba.conf,
> connecting using psql results in logging of authentication failure
> even before a password prompt is provided, nonetheless user is
> subsequently able to connect by providing
Hello,
When client authentication method is set to "pam" in pg_hba.conf,
connecting using psql results in logging of authentication failure
even before a password prompt is provided, nonetheless user is
subsequently able to connect by providing a password. Following is
what is logged:
Password: L
33 matches
Mail list logo
