From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review of GetUserId() Usage |
Date: | 2014-09-23 13:13:03 |
Message-ID: | 20140923131303.GE5311@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> pgstat_get_backend_current_activity()
> Used to decide if the current activity string should be returned or
> not. In my view, this is a clear case which should be addressed
> through has_privs_of_role() instead of requiring the user to
> SET ROLE to each role they are an inheirited member of to query for
> what the other sessions are doing.
>
> pg_signal_backend()
> Used to decide if pg_terminate_backend and pg_cancel_backend are
> allowed. Another case which should be changed over to
> has_privs_of_role(), in my view. Requiring the user to SET ROLE for
> roles which they are an inheirited member of is confusing as it's
> generally not required.
>
> pg_stat_get_activity()
> Used to decide if the state information should be shared.
> My opinion is the same as above- use has_privs_of_role().
> There are a number of other functions in pgstatfuncs.c with similar
> issues (eg: pg_stat_get_backend_activity(),
> pg_stat_get_backend_client_port(), and others).
I think the case for pgstat_get_backend_current_activity() and
pg_stat_get_activity and the other pgstatfuncs.c callers is easy to make
and seems acceptable to me; but I would leave pg_signal_backend out of
that discussion, because it has a potentially harmful side effect. By
requiring SET ROLE you add an extra layer of protection against
mistakes. (Hopefully, pg_signal_backend() is not a routine thing for
well-run systems, which means human intervention, and therefore the room
for error isn't insignificant.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-23 13:14:13 | Re: RLS feature has been committed |
Previous Message | Robert Haas | 2014-09-23 13:09:46 | Re: RLS feature has been committed |