On Tue, May 26, 2015 at 10:06:59PM -0400, Robert Haas wrote:
On Sat, May 23, 2015 at 8:14 PM, Noah Misch n...@leadboat.com wrote:
On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
A protocol extension avoids all of that trouble, and can be target for
9.6 just like any other
On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 3:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
As long as the cookie is randomly generated for each use, then I don't see a
practical problem with that approach.
If the client sets the cookie via an SQL
On 5/20/15 9:38 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby jim.na...@bluetreble.com wrote:
It might be a good idea to do something like this, but it's
significantly more complicated than a protocol-level SET SESSION
AUTHORIZATION. Right now, you can never go backwards
On 5/20/15 5:21 PM, Robert Haas wrote:
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's a reasonable argument. So +1 to protocol from me.
To satisfy Tom, I think this would need to have two modes: one where the
session can never be reset, for ultra security, and
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas wrote:
On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja ma...@joh.to wrote:
Now that we're on the topic of interesting things, would it make sense to
add protocol support for a sort of a
On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja ma...@joh.to wrote:
On 5/20/15 5:21 PM, Robert Haas wrote:
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs si...@2ndquadrant.com
wrote:
That's a reasonable argument. So +1 to protocol from me.
To satisfy Tom, I think this would need to have two
Robert Haas wrote:
On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja ma...@joh.to wrote:
Now that we're on the topic of interesting things, would it make sense to
add protocol support for a sort of a re-authenticate? So a pooler could
first say this user wants to log in from this host,
On 5/20/15 3:31 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas wrote:
After mulling over this a bit, I think that if we're to do something to
improve things here we should redesign the protocol so that it considers
poolers
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby jim.na...@bluetreble.com wrote:
It might be a good idea to do something like this, but it's
significantly more complicated than a protocol-level SET SESSION
AUTHORIZATION. Right now, you can never go backwards from an
authenticated state to an
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's a reasonable argument. So +1 to protocol from me.
To satisfy Tom, I think this would need to have two modes: one where the
session can never be reset, for ultra security, and one where the session
can be reset,
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 19 May 2015 at 16:49, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 19, 2015 at 3:00 PM, Simon Riggs si...@2ndquadrant.com
wrote:
As long as the cookie is randomly generated for each use, then I don't
see a
practical problem
On Mon, May 18, 2015 at 12:33 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Bruce Momjian wrote:
On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net
writes:
On
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 12:29 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 10:53:10 -0400, Robert Haas wrote:
That seems like a kludge to me. If the cookie leaks out somhow, which
it will, then it'll be insecure. I think the
On 2015-05-19 10:53:10 -0400, Robert Haas wrote:
That seems like a kludge to me. If the cookie leaks out somhow, which
it will, then it'll be insecure. I think the way to do this is with a
protocol extension that poolers can enable on request. Then they can
just refuse to forward any reset
On Tue, May 19, 2015 at 3:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
As long as the cookie is randomly generated for each use, then I don't see a
practical problem with that approach.
If the client sets the cookie via an SQL command, that command would
be written to the log, and displayed
On 05/19/2015 09:00 PM, Simon Riggs wrote:
[snip]
I think the idea of having SET SESSION AUTH pass a cookie, and
only let
RESET SESSION AUTH work when the same cookie is supplied, is pretty
reasonable.
As long as the cookie is randomly generated for each use, then I don't
On Tue, May 19, 2015 at 2:46 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 12:29 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 10:53:10 -0400, Robert Haas wrote:
That seems like a kludge to me. If the cookie
On 19 May 2015 at 16:49, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 19, 2015 at 3:00 PM, Simon Riggs si...@2ndquadrant.com
wrote:
As long as the cookie is randomly generated for each use, then I don't
see a
practical problem with that approach.
If the client sets the cookie via
On 19/05/15 20:46, Andres Freund wrote:
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 12:29 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 10:53:10 -0400, Robert Haas wrote:
That seems like a kludge to me. If the cookie leaks out somhow, which
it will,
On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres equivalent of the SUID bit... so why
Bruce Momjian wrote:
On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net
writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres equivalent of the SUID bit... so why not just do something
equivalent?
---
LOGIN-- as user with the appropriate role membership
On 05/13/2015 06:03 AM, Alvaro Herrera wrote:
Craig Ringer wrote:
For some time I've wanted a way to SET SESSION AUTHORISATION or SET
ROLE in a way that cannot simply be RESET, so that a connection may be
handed to a less-trusted service or application to do some work with.
Some years back, I
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres equivalent of the SUID bit... so why not just do something
equivalent?
---
LOGIN-- as user
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Craig Ringer wrote:
For some time I've wanted a way to SET SESSION AUTHORISATION or SET
ROLE in a way that cannot simply be RESET, so that a connection may be
handed to a less-trusted service or application to do some work with.
Some
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
On 12 May 2015 at 21:10, Stephen Frost sfr...@snowman.net wrote:
This can be done without protocol-level changes and with no backward
compatibility impact to existing applications. Any objections?
I don't particularly object but I'm
On 13 May 2015 at 09:55, Stephen Frost sfr...@snowman.net wrote:
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
On 12 May 2015 at 21:10, Stephen Frost sfr...@snowman.net wrote:
This can be done without protocol-level changes and with no backward
compatibility impact to existing
On 12 May 2015 at 21:10, Stephen Frost sfr...@snowman.net wrote:
This can be done without protocol-level changes and with no backward
compatibility impact to existing applications. Any objections?
I don't particularly object but I'm not entirely sure that it's that
simple to clear out the
Craig,
All very interesting, but, to be honest, I don't really have time this
week to chat about it. :( Apologies for that. A couple comments below.
* Craig Ringer (cr...@2ndquadrant.com) wrote:
For some time I've wanted a way to SET SESSION AUTHORISATION or SET
ROLE in a way that cannot
Craig Ringer wrote:
Hi all
For some time I've wanted a way to SET SESSION AUTHORISATION or SET
ROLE in a way that cannot simply be RESET, so that a connection may be
handed to a less-trusted service or application to do some work with.
Some years back, I checked the SQL standard for insight
On Tue, May 12, 2015 at 9:10 AM, Stephen Frost sfr...@snowman.net wrote:
... but, personally, I'd favor
trying to do something at the protocol level instead.
Me, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
31 matches
Mail list logo
