Information of pg_stat_ssl visible to all users
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 pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn
-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t |
(1 row)
2) New session 2 with previously created user:
=> select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn
-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t |
33367 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t |
(2 rows)
Attached is a patch to mask those values to users that should not have
access to it, similarly to the other fields of pg_stat_activity.
Regards,
--
Michael
Attachments:
20150609_pgstat_ssl_leakfix.patchtext/x-diff; charset=US-ASCII; name=20150609_pgstat_ssl_leakfix.patchDownload+23-15
On Jun 9, 2015 6:00 AM, "Michael Paquier" <michael.paquier@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 with a superuser:
=# create role toto login;
CREATE ROLE
=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn
-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(1 row)
2) New session 2 with previously created user:
=> select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn
-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
33367 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(2 rows)
Attached is a patch to mask those values to users that should not have
access to it, similarly to the other fields of pg_stat_activity.
I don't have the thread around right now (on phone), but didn't we discuss
this back around the original submission and decide that this was wanted
behavior?
What actual sensitive data is leaked? If knowing the cipher type makes it
easier to hack you have a broken cipher, don't you?
/Magnus
On Tue, Jun 9, 2015 at 3:27 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Jun 9, 2015 6:00 AM, "Michael Paquier" <michael.paquier@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 with a superuser:
=# create role toto login;
CREATE ROLE
=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(1 row)
2) New session 2 with previously created user:
=> select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
33367 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(2 rows)Attached is a patch to mask those values to users that should not have
access to it, similarly to the other fields of pg_stat_activity.I don't have the thread around right now (on phone), but didn't we discuss
this back around the original submission and decide that this was wanted
behavior?
Looking back at this thread, it is mentioned here:
/messages/by-id/31891.1405175764@sss.pgh.pa.us
What actual sensitive data is leaked? If knowing the cipher type makes it
easier to hack you have a broken cipher, don't you?
I am just wondering if it is a good idea to let other users know the
origin of a connection to all the users. Let's imagine the case where
for example the same user name is used for non-SSL and SSL sessions.
This could give a hint of the activity on the server..
However, feel free to ignore those concerns if you think the current
situation is fine...
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 9, 2015 at 10:55 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Tue, Jun 9, 2015 at 3:27 PM, Magnus Hagander <magnus@hagander.net>
wrote:On Jun 9, 2015 6:00 AM, "Michael Paquier" <michael.paquier@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 with a superuser:
=# create role toto login;
CREATE ROLE
=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(1 row)
2) New session 2 with previously created user:
=> select * from pg_stat_ssl;
pid | ssl | version | cipher | bits |
compression | clientdn-------+-----+---------+-----------------------------+------+-------------+----------
33348 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
33367 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | t
|
(2 rows)Attached is a patch to mask those values to users that should not have
access to it, similarly to the other fields of pg_stat_activity.I don't have the thread around right now (on phone), but didn't we
discuss
this back around the original submission and decide that this was wanted
behavior?Looking back at this thread, it is mentioned here:
/messages/by-id/31891.1405175764@sss.pgh.pa.us
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?
What actual sensitive data is leaked? If knowing the cipher type makes it
easier to hack you have a broken cipher, don't you?
I am just wondering if it is a good idea to let other users know the
origin of a connection to all the users. Let's imagine the case where
for example the same user name is used for non-SSL and SSL sessions.
This could give a hint of the activity on the server..However, feel free to ignore those concerns if you think the current
situation is fine...
Well, I do think the current one is OK, but I don't want to ignore the
comment anyway :) Happy to hear comments from others as well.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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 the whole view shouldn't be accessible to unprivileged
users, except maybe your own row.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut <peter_e@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 the DN field shouldn't be visible to unprivileged users.
What's the argument for that? I mean, the DN field is the equivalent of the
username, and we show the username in pg_stat_activity already. Are you
envisioning a scenario where there is actually something secret in the DN?
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 the dn part?
I guess there's some consistency in actually blocking exactly everything...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut <peter_e@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 the dn part?I guess there's some consistency in actually blocking exactly everything...
One case that I remember popping up every so often was "I don't want
people to know what other customers I have in the same database
cluster". We leak these details all over the place (catalogs that can
be queried directly, as well as pg_stat_activity itself, etc), so just
changing the new view would accomplish nothing. If there's interest in
closing these holes, this might be a first step.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 a benefit in allowing to restrict information about users and
such in other clusters, but changing stat_ssl seeems to be an
inconsequentially small problem on that path.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 2, 2015 at 10:06 PM, Andres Freund <andres@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 a benefit in allowing to restrict information about users and
such in other clusters, but changing stat_ssl seeems to be an
inconsequentially small problem on that path.
We discussed earlier having a "monitoring" role or attribute or something
like that, and I think this would be another case of that. We definitely
want to go towards something like that, but that's not happening in 9.5...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
* Magnus Hagander (magnus@hagander.net) wrote:
On Thu, Jul 2, 2015 at 10:06 PM, Andres Freund <andres@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 a benefit in allowing to restrict information about users and
such in other clusters, but changing stat_ssl seeems to be an
inconsequentially small problem on that path.We discussed earlier having a "monitoring" role or attribute or something
like that, and I think this would be another case of that. We definitely
want to go towards something like that, but that's not happening in 9.5...
Agreed, but if we make this visible to all in 9.5 then we're going to
have a tough time restricting it to just the monitoring role in 9.6, I'm
afraid...
We realize it's a problem, for my 2c, I'd rather not double-down on it
by providing more information which should really be limited to
privileged users.
Thanks,
Stephen
On 7/2/15 3:29 PM, Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@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 the DN field shouldn't be visible to unprivileged
users.What's the argument for that? I mean, the DN field is the equivalent of
the username, and we show the username in pg_stat_activity already. Are
you envisioning a scenario where there is actually something secret in
the DN?
I think the DN is analogous to the remote user name, which we don't
expose for any of the other authentication methods.
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 the dn part?I guess there's some consistency in actually blocking exactly everything...
I think the default approach for security and authentication related
information should be conservative, even if there is not a specific
reason. Or to put it another way: What is the motivation for showing
this information at all?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 7, 2015 at 6:03 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 7/2/15 3:29 PM, Magnus Hagander wrote:
On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@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 the DN field shouldn't be visible to unprivileged
users.What's the argument for that? I mean, the DN field is the equivalent of
the username, and we show the username in pg_stat_activity already. Are
you envisioning a scenario where there is actually something secret in
the DN?I think the DN is analogous to the remote user name, which we don't
expose for any of the other authentication methods.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 the dn part?I guess there's some consistency in actually blocking exactly
everything...
I think the default approach for security and authentication related
information should be conservative, even if there is not a specific
reason. Or to put it another way: What is the motivation for showing
this information at all?
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 consensus in this thread. I
think there are slightly more arguments for limiting the access though.
The question then is, if we want to hide everything, do we care about doing
the "NULL dance", or should we just throw an error for non-superusers
trying to access it?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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 */
values[0] = ObjectIdGetDatum(beentry->st_databaseid);
values[1] = Int32GetDatum(beentry->st_procpid);
values[2] = ObjectIdGetDatum(beentry->st_userid);
...
Isn't that like, essentially, all of them? Sure, if you have a ident
mapping set up, then not, but I have a hard time seing that as a
relevant use case.
I think the default approach for security and authentication related
information should be conservative, even if there is not a specific
reason. Or to put it another way: What is the motivation for showing
this information at all?
That we already show equivalent information and that hiding it from
another place will just be crufty and make monitoring setups more
complex.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@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
some other connection's actual OS username is. You might *guess* that
it's the same as their database username, but you don't know that,
assuming you don't know how they authenticated.
I'm not sure how security-critical this info really is, though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 consensus in this thread.
I think there are slightly more arguments for limiting the access though.The question then is, if we want to hide everything, do we care about
doing the "NULL dance", or should we just throw an error for
non-superusers trying to access it?
I'm going to vote against blocking the entire view for non-superusers.
One of the things people will want to monitor is "are all connection
from subnet X using SSL?" which is most easily answered by joining
pg_stat_activity and pg_stat_ssl.
If we force users to use superuser privs to find this out, then we're
encouraging them to run monitoring as superuser, which is something we
want to get *away* from.
I'd be OK with concealing some columns:
postgres=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits | compression
| clientdn
-----+-----+---------+-----------------------------+------+-------------+----------
37 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | f |
I can see NULLifying cipher and DN columns. The other columns, it's
hard to imagine what use an attacker could put them to that they
wouldn't be able to find out the same information easily using other routes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMbdc060f405288d9c401fea86e722255395c1c33cd8df286b6b751b0c1efcf5e1069d3f63d61496e481d69c64d94ec209@asav-1.01.com
* Josh Berkus (josh@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).I'm having a hard time trying to figure out a consensus in this thread.
I think there are slightly more arguments for limiting the access though.The question then is, if we want to hide everything, do we care about
doing the "NULL dance", or should we just throw an error for
non-superusers trying to access it?I'm going to vote against blocking the entire view for non-superusers.
One of the things people will want to monitor is "are all connection
from subnet X using SSL?" which is most easily answered by joining
pg_stat_activity and pg_stat_ssl.If we force users to use superuser privs to find this out, then we're
encouraging them to run monitoring as superuser, which is something we
want to get *away* from.
I agree with all of this, but I'm worried that if we make it available
now then we may not be able to hide it later, even once we have the
monitoring role defined, because of backwards compatibility concerns.
If we aren't worried about that, then perhaps we can leave it less
strict for 9.5 and then make it stricter for 9.6.
I'd be OK with concealing some columns:
postgres=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits | compression
| clientdn
-----+-----+---------+-----------------------------+------+-------------+----------
37 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | f |I can see NULLifying cipher and DN columns. The other columns, it's
hard to imagine what use an attacker could put them to that they
wouldn't be able to find out the same information easily using other routes.
Perhaps not, but I'm not sure how useful those columns would be to a
monitoring system either.. I'd rather keep it simple.
Thanks!
Stephen
On 07/07/2015 11:29 AM, Stephen Frost wrote:
* Josh Berkus (josh@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).I'm having a hard time trying to figure out a consensus in this thread.
I think there are slightly more arguments for limiting the access though.The question then is, if we want to hide everything, do we care about
doing the "NULL dance", or should we just throw an error for
non-superusers trying to access it?I'm going to vote against blocking the entire view for non-superusers.
One of the things people will want to monitor is "are all connection
from subnet X using SSL?" which is most easily answered by joining
pg_stat_activity and pg_stat_ssl.If we force users to use superuser privs to find this out, then we're
encouraging them to run monitoring as superuser, which is something we
want to get *away* from.I agree with all of this, but I'm worried that if we make it available
now then we may not be able to hide it later, even once we have the
monitoring role defined, because of backwards compatibility concerns.If we aren't worried about that, then perhaps we can leave it less
strict for 9.5 and then make it stricter for 9.6.I'd be OK with concealing some columns:
postgres=# select * from pg_stat_ssl;
pid | ssl | version | cipher | bits | compression
| clientdn
-----+-----+---------+-----------------------------+------+-------------+----------
37 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | f |I can see NULLifying cipher and DN columns. The other columns, it's
hard to imagine what use an attacker could put them to that they
wouldn't be able to find out the same information easily using other routes.Perhaps not, but I'm not sure how useful those columns would be to a
monitoring system either.. I'd rather keep it simple.
So what about making just pid, ssl and compression available? That's
mostly what anyone would want to monitor, except for periodic security
audits. Audits could be done by superuser, no problem.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM34515910fab905de9c19d4b87090bd2e5682a9130633188d844be4a4f18a2d5e38b6f399f60bfee4e2f73df173584007@asav-1.01.com
On Wed, Jul 8, 2015 at 3:29 AM, Stephen Frost <sfrost@snowman.net> wrote:
* Josh Berkus (josh@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).I'm having a hard time trying to figure out a consensus in this thread.
I think there are slightly more arguments for limiting the access though.The question then is, if we want to hide everything, do we care about
doing the "NULL dance", or should we just throw an error for
non-superusers trying to access it?I'm going to vote against blocking the entire view for non-superusers.
One of the things people will want to monitor is "are all connection
from subnet X using SSL?" which is most easily answered by joining
pg_stat_activity and pg_stat_ssl.If we force users to use superuser privs to find this out, then we're
encouraging them to run monitoring as superuser, which is something we
want to get *away* from.I agree with all of this, but I'm worried that if we make it available
now then we may not be able to hide it later, even once we have the
monitoring role defined, because of backwards compatibility concerns.If we aren't worried about that, then perhaps we can leave it less
strict for 9.5 and then make it stricter for 9.6.
Agreed. It is better to make things strict first and relax afterwards
from the user prospective, so I would vote for something in this
direction. We could relax it with this monitoring ACL afterwards in
9.6, still what I think we are missing here are reactions from the
field, and I suspect that taking the most careful approach (hiding a
maximum of fields to non-authorized users) will pay better in the long
term. I am also suspecting that if we let it as-is cloud deployments
of Postgres (Heroku for example) are going to patch this view with ACL
checks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 7, 2015 at 12:57:58PM -0400, Tom Lane wrote:
Andres Freund <andres@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
some other connection's actual OS username is. You might *guess* that
it's the same as their database username, but you don't know that,
assuming you don't know how they authenticated.I'm not sure how security-critical this info really is, though.
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:
=> \du
List of roles
Role name | Attributes | Member of
----------------+------------------------------------------------+-----------
aafgrwewediiqz | 20 connections | {}
aaszwkfnholarh | 20 connections | {}
aatbelxbaeriwy | 20 connections | {}
aaxiwolkcxmbxo | 20 connections | {}
abbyljzgqaonjb | 20 connections | {}
I can see them having problems with a user being able to see the SSL
remote user names of all connected users.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
remote user names of all connected users.
Yep, and I can imagine that this is the case of any company managing cloud
nodes with Postgres embedded, and at least to me that's a real concern.
--
Michael