Horton

Thread

  1. pg_stat_replication security

    Magnus Hagander <magnus@hagander.net> — 2011-01-16T14:35:34Z

    pg_stat_replication shows all replication information to all users, no
requirement to be a superuser or anything. That leaks a bunch of
information that regular pg_stat_activity doesn't - such as clients IP
addresses. And also of course all the replication info itself, which
may or may not be a problem.

I suggest pg_stat_replication do just like pg_stat_activity, which is
return NULL in most fields if the user isn't
(superuser||same_user_as_that_session).


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  2. Re: pg_stat_replication security

    Josh Berkus <josh@agliodbs.com> — 2011-01-16T20:51:56Z

    > I suggest pg_stat_replication do just like pg_stat_activity, which is
> return NULL in most fields if the user isn't
> (superuser||same_user_as_that_session).

What session would that be, exactly?

I suggest instead either "superuser" or "replication" permissions.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com

  3. Re: pg_stat_replication security

    Magnus Hagander <magnus@hagander.net> — 2011-01-16T20:56:01Z

    On Sun, Jan 16, 2011 at 21:51, Josh Berkus <josh@agliodbs.com> wrote:
>
>> I suggest pg_stat_replication do just like pg_stat_activity, which is
>> return NULL in most fields if the user isn't
>> (superuser||same_user_as_that_session).
>
> What session would that be, exactly?

The user doing the query to pg_stat_replication being the same as the
user running the replication.


> I suggest instead either "superuser" or "replication" permissions.

That's another idea.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  4. Re: pg_stat_replication security

    Josh Berkus <josh@agliodbs.com> — 2011-01-16T20:57:23Z

    >> I suggest instead either "superuser" or "replication" permissions.
> 
> That's another idea.

Oh, wait.  I take that back ... we're trying to encourage users NOT to
use the "replication" user as a login, yes?

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com

  5. Re: pg_stat_replication security

    Magnus Hagander <magnus@hagander.net> — 2011-01-17T10:51:45Z

    On Sun, Jan 16, 2011 at 21:57, Josh Berkus <josh@agliodbs.com> wrote:
>
>>> I suggest instead either "superuser" or "replication" permissions.
>>
>> That's another idea.
>
> Oh, wait.  I take that back ... we're trying to encourage users NOT to
> use the "replication" user as a login, yes?

yeah.

Here's a patch that limits it to superuser only. We can't easily match
it to the user of the session given the way the walsender data is
returned - it doesn't contain the user information. But limiting it to
superuser only seems perfectly reasonable and in line with the
encouragement not to use the replication user for login.

Objections?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  6. Re: pg_stat_replication security

    Itagaki Takahiro <itagaki.takahiro@gmail.com> — 2011-01-17T11:11:04Z

    On Mon, Jan 17, 2011 at 19:51, Magnus Hagander <magnus@hagander.net> wrote:
> Here's a patch that limits it to superuser only. We can't easily match
> it to the user of the session given the way the walsender data is
> returned - it doesn't contain the user information. But limiting it to
> superuser only seems perfectly reasonable and in line with the
> encouragement not to use the replication user for login.
>
> Objections?

It hides all fields in pg_stat_wal_senders(). Instead, can we just
revoke usage of the function and view?  Or, do we have some plans
to add fields which normal users can see?

-- 
Itagaki Takahiro

  7. Re: pg_stat_replication security

    Magnus Hagander <magnus@hagander.net> — 2011-01-17T12:14:37Z

    On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Mon, Jan 17, 2011 at 19:51, Magnus Hagander <magnus@hagander.net> wrote:
>> Here's a patch that limits it to superuser only. We can't easily match
>> it to the user of the session given the way the walsender data is
>> returned - it doesn't contain the user information. But limiting it to
>> superuser only seems perfectly reasonable and in line with the
>> encouragement not to use the replication user for login.
>>
>> Objections?
>
> It hides all fields in pg_stat_wal_senders(). Instead, can we just
> revoke usage of the function and view?  Or, do we have some plans
> to add fields which normal users can see?

Yes, for consistency with pg_stat_activity. We let all users see which
other sessions are there, but not what they're doing - seems
reasonable to have the same definitions for replication sessions as
other sessions.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  8. Re: pg_stat_replication security

    Magnus Hagander <magnus@hagander.net> — 2011-01-23T16:28:57Z

    On Mon, Jan 17, 2011 at 13:14, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro
> <itagaki.takahiro@gmail.com> wrote:
>> On Mon, Jan 17, 2011 at 19:51, Magnus Hagander <magnus@hagander.net> wrote:
>>> Here's a patch that limits it to superuser only. We can't easily match
>>> it to the user of the session given the way the walsender data is
>>> returned - it doesn't contain the user information. But limiting it to
>>> superuser only seems perfectly reasonable and in line with the
>>> encouragement not to use the replication user for login.
>>>
>>> Objections?
>>
>> It hides all fields in pg_stat_wal_senders(). Instead, can we just
>> revoke usage of the function and view?  Or, do we have some plans
>> to add fields which normal users can see?
>
> Yes, for consistency with pg_stat_activity. We let all users see which
> other sessions are there, but not what they're doing - seems
> reasonable to have the same definitions for replication sessions as
> other sessions.

Committed.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/