On Sep 1, 2015 4:37 AM, "Michael Paquier" wrote:
>
> On Tue, Sep 1, 2015 at 4:23 AM, Peter Eisentraut wrote:
> > On 8/31/15 9:13 AM, Andres Freund wrote:
> >> I'm just saying that we should strive to behave at least somewhat
> >> consistently, and
On 8/31/15 9:13 AM, Andres Freund wrote:
> I'm just saying that we should strive to behave at least somewhat
> consistently, and change everything at once, not piecemal. Because the
> latter will not decrease the pain of migrating to a new model in a
> relevant way while making the system harder
On Tue, Sep 1, 2015 at 4:23 AM, Peter Eisentraut wrote:
> On 8/31/15 9:13 AM, Andres Freund wrote:
>> I'm just saying that we should strive to behave at least somewhat
>> consistently, and change everything at once, not piecemal. Because the
>> latter will not decrease the pain
* Magnus Hagander (mag...@hagander.net) wrote:
> On Sat, Aug 29, 2015 at 10:27 PM, Bruce Momjian wrote:
> > I can see them having problems with a user being able to see the SSL
> > remote user names of all connected users.
>
> I'm pretty sure Heroku don't use client
On 2015-08-31 09:06:27 -0400, Stephen Frost wrote:
> Perhaps it really isn't moving the bar all that much but at least for a
> number of our users, it's increasing what they have to be worrying about
> ("well, we knew usernames were an issue, but now we also have to worry
> about system usersnames
On Mon, Aug 31, 2015 at 2:17 PM, Michael Paquier
wrote:
> On Mon, Aug 31, 2015 at 9:04 PM, Magnus Hagander
> wrote:
> >
> >
> > On Sun, Aug 30, 2015 at 5:35 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >>
> >>
> >>
> >> On Sun,
On 2015-08-31 14:29:10 +0200, Andres Freund wrote:
> On 2015-08-31 21:17:48 +0900, Michael Paquier wrote:
> > How can you be sure as well that all such deployments would use random
> > CN fields and/or random usernames? We have no guarantee of that as
> > well.
>
> Sorry, but this is a bit
On Sun, Aug 30, 2015 at 5:35 AM, Michael Paquier
wrote:
>
>
> On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote:
>
>> I know I am coming in late here, but I know Heroku uses random user
>> names to allow a cluster to have per-user databases without showing
>>
On Sat, Aug 29, 2015 at 10:27 PM, Bruce Momjian wrote:
> On Tue, Jul 7, 2015 at 12:57:58PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote:
> > >> I think the DN is analogous to the remote user
On 2015-08-31 21:17:48 +0900, Michael Paquier wrote:
> How can you be sure as well that all such deployments would use random
> CN fields and/or random usernames? We have no guarantee of that as
> well.
Sorry, but this is a bit ridiculous.
Greetings,
Andres Freund
--
Sent via pgsql-hackers
On Mon, Aug 31, 2015 at 9:04 PM, Magnus Hagander wrote:
>
>
> On Sun, Aug 30, 2015 at 5:35 AM, Michael Paquier
> wrote:
>>
>>
>>
>> On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote:
>>>
>>> I know I am coming in late here, but I know Heroku
On 2015-08-30 11:33:28 -0400, Stephen Frost wrote:
Yeah, I'm not really thrilled with all of this information being
available to everyone on the system. We already get ding'd by people
for not limiting who can see what connections there are to the database
and this is doubling-down on that.
* Michael Paquier (michael.paqu...@gmail.com) wrote:
On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote:
I know I am coming in late here, but I know Heroku uses random user
names to allow a cluster to have per-user databases without showing
external user name details:
[...]
I can
On Tue, Jul 7, 2015 at 12:57:58PM -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote:
I think the DN is analogous to the remote user name, which we don't
expose for any of the other authentication methods.
Huh?
On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote:
I know I am coming in late here, but I know Heroku uses random user
names to allow a cluster to have per-user databases without showing
external user name details:
[...]
I can see them having problems with a user being able to see the SSL
On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote:
I think the DN is analogous to the remote user name, which we don't
expose for any of the other authentication methods.
Huh?
Datum
pg_stat_get_activity(PG_FUNCTION_ARGS)
{
/* Values available to all callers */
On 7/2/15 3:29 PM, Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 6/10/15 2:17 AM, Magnus Hagander wrote:
AIUI that one was just about the DN field, and not about the rest. If I
understand you correctly,
Andres Freund and...@anarazel.de writes:
On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote:
I think the DN is analogous to the remote user name, which we don't
expose for any of the other authentication methods.
Huh?
Peter's exactly right: there is no other case where you can tell what
On Tue, Jul 7, 2015 at 6:03 PM, Peter Eisentraut pete...@gmx.net wrote:
On 7/2/15 3:29 PM, Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 6/10/15 2:17 AM, Magnus Hagander wrote:
AIUI that one was just
On 07/07/2015 11:29 AM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
On 07/07/2015 09:06 AM, Magnus Hagander wrote:
To make it accessible to monitoring systems that don't run as superuser
(which should be most monitoring systems, but we have other cases making
that hard as
On 07/07/2015 09:06 AM, Magnus Hagander wrote:
To make it accessible to monitoring systems that don't run as superuser
(which should be most monitoring systems, but we have other cases making
that hard as has already been mentioned upthread).
I'm having a hard time trying to figure out a
* Josh Berkus (j...@agliodbs.com) wrote:
On 07/07/2015 09:06 AM, Magnus Hagander wrote:
To make it accessible to monitoring systems that don't run as superuser
(which should be most monitoring systems, but we have other cases making
that hard as has already been mentioned upthread).
On Wed, Jul 8, 2015 at 3:29 AM, Stephen Frost sfr...@snowman.net wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
On 07/07/2015 09:06 AM, Magnus Hagander wrote:
To make it accessible to monitoring systems that don't run as superuser
(which should be most monitoring systems, but we have
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jul 2, 2015 at 10:06 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-02 16:52:01 -0300, Alvaro Herrera wrote:
If there's interest in closing these holes, this might be a first
I don't think such an isolated attempt buys us
On 6/10/15 2:17 AM, Magnus Hagander wrote:
AIUI that one was just about the DN field, and not about the rest. If I
understand you correctly, you are referring to the whole thing, not just
one field?
I think at least the DN field shouldn't be visible to unprivileged users.
Actually, I think
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut pete...@gmx.net wrote:
On 6/10/15 2:17 AM, Magnus Hagander wrote:
AIUI that one was just about the DN field, and not about the rest. If I
understand you correctly, you are referring to the whole thing, not just
one field?
I think at least
Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut pete...@gmx.net wrote:
Actually, I think the whole view shouldn't be accessible to unprivileged
users, except maybe your own row.
I could go for some of the others if we think there's reason, but I don't
understand
On Thu, Jul 2, 2015 at 10:06 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-02 16:52:01 -0300, Alvaro Herrera wrote:
If there's interest in closing these holes, this might be a first
I don't think such an isolated attempt buys us anything except maybe
unsatisfied users.
I can see
On Tue, Jun 9, 2015 at 10:55 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Tue, Jun 9, 2015 at 3:27 PM, Magnus Hagander mag...@hagander.net
wrote:
On Jun 9, 2015 6:00 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
Hi all,
I should have noticed that before, but it
On Jun 9, 2015 6:00 AM, Michael Paquier michael.paqu...@gmail.com wrote:
Hi all,
I should have noticed that before, but it happens that pg_stat_ssl
leaks information about the SSL status of all the users connected to a
server. Let's imagine for example:
1) Session 1 connected through SSL
On Tue, Jun 9, 2015 at 3:27 PM, Magnus Hagander mag...@hagander.net wrote:
On Jun 9, 2015 6:00 AM, Michael Paquier michael.paqu...@gmail.com wrote:
Hi all,
I should have noticed that before, but it happens that pg_stat_ssl
leaks information about the SSL status of all the users connected to
Hi all,
I should have noticed that before, but it happens that pg_stat_ssl
leaks information about the SSL status of all the users connected to a
server. Let's imagine for example:
1) Session 1 connected through SSL with a superuser:
=# create role toto login;
CREATE ROLE
=# select * from
32 matches
Mail list logo