Re: SET ROLE documentation not entirely correct

From: Joe Conway <mail(at)joeconway(dot)com>
To: steven(dot)winfield(at)cantabcapital(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: SET ROLE documentation not entirely correct
Date: 2019-04-24 19:23:19
Message-ID: 03796ce5-8366-cd32-0436-9981ffbeb993@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On 4/23/19 11:52 AM, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/11/sql-set-role.html
> Description:
>
> In the course of trying to sanitise our roles and permissions I found the
> notes in the SET ROLE docs a little misleading:
>
> "If the session user role has the INHERITS attribute, then it automatically
> has all the privileges of every role that it could SET ROLE to; in this case
> SET ROLE effectively drops all the privileges assigned directly to the
> session user and to the other roles it is a member of, leaving only the
> privileges available to the named role."

> This doesn't seem to be true. Consider the following:

Additionally s/INHERITS/INHERIT/

And similarly this sentence is wrong or at least not completely clear:
8<-----------
The specified role_name must be a role that the current session user is
a member of.
8<-----------

The wording should be something like

8<-----------
The specified role_name must be a role that the current session user is
a member of directly or indirectly.
8<-----------

I believe the paragraph you cite should be reworded, but I am at a loss
as to how best to describe the actual situation clearly. Maybe something
like:

8<-----------
If the session user role has the INHERIT attribute, then it
automatically has all the privileges of every role that it is a member
of directly, and any that it is a member of indirectly which is not
blocked by a NOINHERIT attribute of another reachable role; in this case
SET ROLE effectively drops all the privileges assigned directly to the
session user and to the other roles it is a member of, leaving only the
privileges available to the named role.
8<-----------

Thoughts?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message PG Doc comments form 2019-04-25 10:57:00 cube grouping
Previous Message Peter Eisentraut 2019-04-24 18:58:27 Re: Passphrase protected SSL key and reloads