On 01/29/2014 10:19 AM, Simon Riggs wrote:
> No specific reason that I can recall but replication is heavily
> protected by layers of security.
>
> pg_stat_replication is a join with pg_stat_activity, so some of the
> info is open, some closed. It seems possible to relax that.
I'm all for the ide
On 28 January 2014 20:14, Josh Berkus wrote:
> On 01/28/2014 12:10 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> For example, I would really like to GRANT an unpriv user access to the
>>> WAL columns in pg_stat_replication so that I can monitor replication
>>> delay without granting superuser pe
On Tue, Jan 28, 2014 at 8:17 PM, Stephen Frost wrote:
> Greg,
>
> * Greg Stark (st...@mit.edu) wrote:
>> On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus wrote:
>> > For example, I would really like to GRANT an unpriv user access to the
>> > WAL columns in pg_stat_replication so that I can monitor r
Greg,
* Greg Stark (st...@mit.edu) wrote:
> On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus wrote:
> > For example, I would really like to GRANT an unpriv user access to the
> > WAL columns in pg_stat_replication so that I can monitor replication
> > delay without granting superuser permissions.
>
On 01/28/2014 12:10 PM, Tom Lane wrote:
> Josh Berkus writes:
>> For example, I would really like to GRANT an unpriv user access to the
>> WAL columns in pg_stat_replication so that I can monitor replication
>> delay without granting superuser permissions.
>
> Just out of curiosity, why is that s
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> Really the only way we're going to solve this is to make column
> permissions on special system views fully configurable.
We really need to fully support column and row-level security to provide
the kind of granularty which we do today (but force o
Josh Berkus writes:
> For example, I would really like to GRANT an unpriv user access to the
> WAL columns in pg_stat_replication so that I can monitor replication
> delay without granting superuser permissions.
Just out of curiosity, why is that superuser-only at all? AFAICS the
hidden columns
On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus wrote:
> Really the only way we're going to solve this is to make column
> permissions on special system views fully configurable.
>
> For example, I would really like to GRANT an unpriv user access to the
> WAL columns in pg_stat_replication so that I
On 01/28/2014 07:27 AM, Greg Stark wrote:
> Why is application_name useful for users who aren't the DBA and aren't
> the user in question. The sql_query would probably be more useful than
> application_name but we hide that...
I have non-privileged monitoring scripts do counts of connections by
ap
On Tue, Jan 28, 2014 at 11:28 AM, Greg Stark wrote:
> Well maybe. Or we want this useful information at a finer granularity
> than "everyone or nobody" and given the choice we prefer to have it
> than not.
Anyways, I don't feel incredibly strongly about this. I think we
should default any user-da
On Tue, Jan 28, 2014 at 7:49 AM, Tom Lane wrote:
> Oh really. So, to clean up after their own ill-considered decision,
> they'd like to take useful information away from everybody.
Well maybe. Or we want this useful information at a finer granularity
than "everyone or nobody" and given the choic
On 2014-01-28 07:27:52 -0800, Greg Stark wrote:
> > And all of that without removing a valuable debugging/tracing tool from
> > other users.
>
> Why is application_name useful for users who aren't the DBA and aren't
> the user in question. The sql_query would probably be more useful than
> applica
Greg Stark writes:
> The problem with that is that it doesn't just hide it. It removes the
> debugging information altogether. Even the administrator of the
> application itself and the DBA won't have this information. The reason
> the Gem is putting that information in application_name is precise
On Sat, Jan 25, 2014 at 2:33 AM, Magnus Hagander wrote:
>
> With that many options of "hiding" it, I would still argue for just picking
> one of those.
>
> For example, of Heroku wants to protect their customers against the
> behaviour of the pg gem, you can for example set PGAPPNAME in the
> envi
On Fri, Jan 24, 2014 at 5:21 PM, Harold Giménez wrote:
> On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander
> wrote:
> >
> > On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark wrote:
> >>
> >> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
> >> > Probably Heroku has some more specific exploit case
On Sat, Jan 25, 2014 at 10:42 AM, Greg Stark wrote:
> On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander
> wrote:
> > What actually happens if you set the application_name in the connection
> > string in that environment? Does it override it to it's own default? If
> so,
> > the developers there c
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander wrote:
> What actually happens if you set the application_name in the connection
> string in that environment? Does it override it to it's own default? If so,
> the developers there clearly need to be taught about
> fallback_application_name.
>
> An
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander wrote:
>
> On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark wrote:
>>
>> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
>> > Probably Heroku has some more specific exploit case to be concerned
>> > about here; if so, might I suggest taking it up w
On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark wrote:
> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
> > Probably Heroku has some more specific exploit case to be concerned
> > about here; if so, might I suggest taking it up with the -security list?
>
> I don't think there's a specific vulne
On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
> Probably Heroku has some more specific exploit case to be concerned
> about here; if so, might I suggest taking it up with the -security list?
I don't think there's a specific vulnerability that needs to be kept
secret here.
Here's an example
On Tue, Jan 21, 2014 at 7:38 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> Definitely agree with you. This is just an example of how running
>> monitoring as superuser is not necessarily the worst thing, and there
>> are other reasons to do it already.
>
> It's a horrib
Stephen Frost wrote:
> Harold Giménez (har...@heroku.com) wrote:
>
>> This is just an example of how running monitoring as superuser
>> is not necessarily the worst thing, and there are other reasons
>> to do it already.
>
> It's a horrible thing and that isn't a good reason- if my
> database isn'
On 01/21/2014 05:22 PM, Mark Kirkwood wrote:
> If said malicious attacker can log into postgres and issue its own
> queries, and connect to other database then you are in serious trouble
> already.
>
> I also wonder that if such an attacker knows the application name, that
> would suggest that the
On 01/21/2014 05:21 PM, Andres Freund wrote:
> I think the only realistic thing is a "monitoring" capability, like we
> have "replication". GRANT/REVOKE doesn't even come close to being able
> to generically allow to grant permissions of even the moderate
> complexity pg_stat_get_activity() has.
T
Andres Freund writes:
> On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
>> Don't know what folks think of removing those in-the-function checks in
>> favor of trusting the grant/revoke system to not allow those functions
>> to be called unless you have EXECUTE privileges on them..
> Well, they
On Tue, Jan 21, 2014 at 5:22 PM, Mark Kirkwood
wrote:
> On 22/01/14 13:32, Harold Giménez wrote:
>>
>> On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
>>>
>>> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
I don't know of a client where it can't be overridden. The
On 22/01/14 13:32, Harold Giménez wrote:
On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
I don't know of a client where it can't be overridden. The friction
occurs when by default it sets it to something useful to a develope
On 2014-01-21 20:18:54 -0500, Stephen Frost wrote:
> > > Don't know what folks think of removing those in-the-function checks in
> > > favor of trusting the grant/revoke system to not allow those functions
> > > to be called unless you have EXECUTE privileges on them..
> >
> > Well, they *do* ret
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
> > > It would be really nice to be able to GRANT/REVOKE on some of these
> > > special system views ...
>
> Just define a security definer wrapper func
On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
> > It would be really nice to be able to GRANT/REVOKE on some of these
> > special system views ...
Just define a security definer wrapper function + view, that afair works
perfectly fine.
> Well, we ac
* Josh Berkus (j...@agliodbs.com) wrote:
> It would be really nice to be able to GRANT/REVOKE on some of these
> special system views ...
Well, we actually *can* issue grant/revoke against the underlying
function calls, but we are also doing permissions checks *in* those
functions, ignoring our ow
On Tue, Jan 21, 2014 at 4:53 PM, Josh Berkus wrote:
> It would be really nice to be able to GRANT/REVOKE on some of these
> special system views ...
I think this would be ideal, too.
-Harold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 01/21/2014 04:12 AM, Stephen Frost wrote:
>> It also means that monitoring tools must run as superuser to see
>> > information they require, which to me is a total showstopper.
> We've already got *far* too much of that going on for my taste. I'd
> love to see a comprehensive solution to this p
On Tue, Jan 21, 2014 at 4:46 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> This is a separate topic, but in such a case I'd want to know that
>> I've reached max_connections, which may not be a problem if I just
>> don't need any more connections, but I still need somet
* Harold Giménez (har...@heroku.com) wrote:
> This is a separate topic, but in such a case I'd want to know that
> I've reached max_connections, which may not be a problem if I just
> don't need any more connections, but I still need something connecting
> to make sure the service is available at a
On Tue, Jan 21, 2014 at 4:38 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> Definitely agree with you. This is just an example of how running
>> monitoring as superuser is not necessarily the worst thing, and there
>> are other reasons to do it already.
>
> It's a horrib
* Harold Giménez (har...@heroku.com) wrote:
> Definitely agree with you. This is just an example of how running
> monitoring as superuser is not necessarily the worst thing, and there
> are other reasons to do it already.
It's a horrible thing and that isn't a good reason- if my database isn't
acc
On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
>> I don't know of a client where it can't be overridden. The friction
>> occurs when by default it sets it to something useful to a developer
>> (useful eg: to find what process
On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
> I don't know of a client where it can't be overridden. The friction
> occurs when by default it sets it to something useful to a developer
> (useful eg: to find what process is holding a lock), but is not
> possible to conceal from o
On Tue, Jan 21, 2014 at 4:01 PM, Bruce Momjian wrote:
> On Tue, Jan 21, 2014 at 03:57:37PM -0800, Harold Giménez wrote:
>> > It also means that monitoring tools must run as superuser to see
>> > information they require, which to me is a total showstopper.
>>
>>
>> Well, the fact is that if you do
On Tue, Jan 21, 2014 at 7:25 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>>> If you want control over visibility of application_name, it should be
>>> done with a column privilige granted to a system role, or something like
>>> that - so the abilit
On Tue, Jan 21, 2014 at 03:57:37PM -0800, Harold Giménez wrote:
> > It also means that monitoring tools must run as superuser to see
> > information they require, which to me is a total showstopper.
>
>
> Well, the fact is that if you don't run monitoring tools as superuser,
> there may not be en
On Tue, Jan 21, 2014 at 12:31 AM, Craig Ringer wrote:
>
> On 01/21/2014 04:19 PM, Heikki Linnakangas wrote:
> > On 01/21/2014 07:22 AM, Harold Giménez wrote:
> >> First of all, I apologize for submitting a patch and missing the
> >> commitfest
> >> deadline. Given the size of the patch, I thought
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost wrote:
> > Not unless we change it to allow read-access to all tables to allow for
> > pg_dump to work...
>
> That sounds more like CAP_DUMP than CAP_BACKUP :)
Well, perhaps CAP_READONLY (or READALL?)
On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > Isn't CAP_BACKUP pretty much the REPLICATION privilege?
>
> Not unless we change it to allow read-access to all tables to allow for
> pg_dump to work...
>
That sounds more like CAP_DUMP tha
* Magnus Hagander (mag...@hagander.net) wrote:
> Isn't CAP_BACKUP pretty much the REPLICATION privilege?
Not unless we change it to allow read-access to all tables to allow for
pg_dump to work...
Thanks,
Stephen
signature.asc
Description: Digital signature
On Tue, Jan 21, 2014 at 2:41 PM, Alvaro Herrera wrote:
> Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) wrote:
> > > It also means that monitoring tools must run as superuser to see
> > > information they require, which to me is a total showstopper.
> >
> > We've already got *far*
Stephen Frost writes:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> If you want control over visibility of application_name, it should be
>> done with a column privilige granted to a system role, or something like
>> that - so the ability to see it can be given to "public" on default
>> (thus
Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
> > It also means that monitoring tools must run as superuser to see
> > information they require, which to me is a total showstopper.
>
> We've already got *far* too much of that going on for my taste. I'd
> love to see a compr
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> It also means that monitoring tools must run as superuser to see
> information they require, which to me is a total showstopper.
We've already got *far* too much of that going on for my taste. I'd
love to see a comprehensive solution to this problem
On 01/21/2014 04:19 PM, Heikki Linnakangas wrote:
> On 01/21/2014 07:22 AM, Harold Giménez wrote:
>> First of all, I apologize for submitting a patch and missing the
>> commitfest
>> deadline. Given the size of the patch, I thought I'd submit it for your
>> consideration regardless.
>>
>> This patc
On 01/21/2014 07:22 AM, Harold Giménez wrote:
First of all, I apologize for submitting a patch and missing the commitfest
deadline. Given the size of the patch, I thought I'd submit it for your
consideration regardless.
This patch prevents non-superusers from viewing other user's
pg_stat_activit
52 matches
Mail list logo
