Review of GetUserId() Usage

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Review of GetUserId() Usage
Date: 2014-09-23 06:28:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


While looking through the GetUserId() usage in the backend, I couldn't
help but notice a few rather questionable cases that, in my view,
should be cleaned up.

As a reminder, GetUserId() returns the OID of the user we are
generally operating as (eg: whatever the 'role' is, as GetUserId()
respects SET ROLE). It does NOT include roles which we currently have
the privileges of (that would be has_privs_of_role()), nor roles which
we could SET ROLE to (that's is_member_of_role, or check_is_... if you
want to just error out in failure cases).

On to the list-

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.

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.

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).

Changing these would make things easier for some of our users, I'm




Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-09-23 06:33:37 Re: Commitfest status
Previous Message Peter Geoghegan 2014-09-23 06:15:36 Re: RLS feature has been committed