On Tue, May 26, 2015 at 10:06:59PM -0400, Robert Haas wrote:
> On Sat, May 23, 2015 at 8:14 PM, Noah Misch 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 approach we mi
On Sat, May 23, 2015 at 8:14 PM, Noah Misch wrote:
> On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
>> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs wrote:
>> > As long as the cookie is randomly generated for each use, then I don't see
>> > a
>> > practical problem with that approac
On Fri, May 22, 2015 at 2:11 PM, Jim Nasby wrote:
>> Uh, I don't have a clue what you mean when you say "the middle ground
>> of not doing de-auth right now".
>
> Don't allow a backend to move back into a de-authenticated state.
>
> Basically, allow a special connection mode that does nothing but
On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs 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
On 5/20/15 9:38 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby 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
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby 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 unauthenticated state,
On 5/20/15 3:31 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
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 explicitely. Right now
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja 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
>>
Robert Haas wrote:
> On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja 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", then
On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja wrote:
> On 5/20/15 5:21 PM, Robert Haas wrote:
>> On Tue, May 19, 2015 at 5:02 PM, Simon Riggs
>> 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
On 5/20/15 5:21 PM, Robert Haas wrote:
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs 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
On Tue, May 19, 2015 at 5:02 PM, Simon Riggs 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, which allows secur
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 19 May 2015 at 16:49, Robert Haas wrote:
>
> > On Tue, May 19, 2015 at 3:00 PM, Simon Riggs
> > wrote:
> > > As long as the cookie is randomly generated for each use, then I don't
> > see a
> > > practical problem with that approach.
> >
> > If t
On 19 May 2015 at 16:49, Robert Haas wrote:
> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs
> 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 woul
On Tue, May 19, 2015 at 3:00 PM, Simon Riggs 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 in pg_stat_activity.
On Tue, May 19, 2015 at 2:46 PM, 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 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
>>
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
see
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 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 insecu
On 18 May 2015 at 12:33, Alvaro Herrera 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?=
> writes:
> > > >>On the other hand, ISTM that what we all inte
On 2015-05-19 14:41:06 -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 12:29 PM, Andres Freund 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 way to do th
On Tue, May 19, 2015 at 12:29 PM, Andres Freund 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 way to do this is with a
>> protocol extension that poolers can enabl
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 "re
On Mon, May 18, 2015 at 12:33 PM, Alvaro Herrera
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?=
>> > >writes:
>> > >>On the other hand, ISTM that what we
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?=
> > >writes:
> > >>On the other hand, ISTM that what we all intend to achieve is some
> > >>Postgres equivalent of the
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?= 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 someth
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= 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
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= 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 / privilege?
> .
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,
* 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.
>
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
On 13 May 2015 at 09:55, Stephen Frost wrote:
> Craig,
>
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
> > On 12 May 2015 at 21:10, Stephen Frost wrote:
> > > > This can be done without protocol-level changes and with no backward
> > > > compatibility impact to existing applications. Any objec
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 12 May 2015 at 21:10, Stephen Frost 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 enti
On 12 May 2015 at 21:10, Stephen Frost 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 cookie val
On Tue, May 12, 2015 at 9:10 AM, Stephen Frost 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 mailing list (pgsql-hac
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 canno
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.
This is most useful for connection pools, where it's currently necessary to
h
36 matches
Mail list logo
