On 5/27/13, Craig Ringer cr...@2ndquadrant.com 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
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 report
On Tue, May 28, 2013 at 2:32 PM, Craig Ringer cr...@2ndquadrant.com 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
On Tue, May 28, 2013 at 5:04 PM, Amit Langote amitlangot...@gmail.com wrote:
On Tue, May 28, 2013 at 2:32 PM, Craig Ringer cr...@2ndquadrant.com 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
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 report
On 05/28/2013 04:04 PM, Amit Langote wrote:
On Tue, May 28, 2013 at 2:32 PM, Craig Ringer cr...@2ndquadrant.com 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
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 amitlangot...@gmail.com
Date: Fri, May 17, 2013 at 1:29 AM
Subject: Re: [HACKERS] Logging of PAM Authentication Failure
To: Tom Lane t...@sss.pgh.pa.us
Cc: Andres Freund and...@2ndquadrant.com, Kyotaro HORIGUCHI
kyota.horigu...@gmail.com, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp
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
On Thu, May 16, 2013 at 3:53 PM, Amit Langote amitlangot...@gmail.com 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
On 2013-05-16 17:35:10 +0900, Amit Langote wrote:
On Thu, May 16, 2013 at 3:53 PM, Amit Langote amitlangot...@gmail.com 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
On Thu, May 16, 2013 at 8:01 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-05-16 17:35:10 +0900, Amit Langote wrote:
On Thu, May 16, 2013 at 3:53 PM, Amit Langote amitlangot...@gmail.com
wrote:
Attached herewith is a patch based on description in my previous mail.
This patch
Amit Langote amitlangot...@gmail.com writes:
On Thu, May 16, 2013 at 8:01 PM, Andres Freund and...@2ndquadrant.com 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
On Fri, May 17, 2013 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Langote amitlangot...@gmail.com writes:
On Thu, May 16, 2013 at 8:01 PM, Andres Freund and...@2ndquadrant.com
wrote:
I unfortunately have to say I don't really see the point of this. The
cost of the additional
On 2013-05-17 01:29:25 +0900, Amit Langote wrote:
On Fri, May 17, 2013 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Langote amitlangot...@gmail.com writes:
On Thu, May 16, 2013 at 8:01 PM, Andres Freund and...@2ndquadrant.com
wrote:
I unfortunately have to say I don't really see
Andres Freund and...@2ndquadrant.com 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
On Fri, May 17, 2013 at 1:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
On Thu, May 16, 2013 at 7:01 AM, Andres Freund and...@2ndquadrant.com 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
On Tue, May 14, 2013 at 11:20 AM, Amit Langote amitlangot...@gmail.com 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
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 to
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 quite
On Wed, May 15, 2013 at 11:04 PM, Kyotaro HORIGUCHI
kyota.horigu...@gmail.com 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
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 PQconnectPoll() is
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
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()
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 that's
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) ==
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, if
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
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
On Wed, May 8, 2013 at 10:40 PM, Amit Langote amitlangot...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, May 8, 2013 at 10:40 PM, Amit Langote amitlangot...@gmail.com 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
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:
33 matches
Mail list logo
