Re: SET ROLE documentation not entirely correct

Joe Conway <[email protected]> Thu, 25 Apr 2019 11:46:00 -0400
Newsgroups	gmane.comp.db.postgresql.devel.documentation
Message-ID	<[email protected]>
On 4/25/19 11:25 AM, Steven Winfield wrote:
>> Additionally s/INHERITS/INHERIT/
> 
> Good spot.
> 
>> 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<-----------
> 
> That’s certainly much better (perhaps with a comma after “of”, if I’m
> being pedantic).
> 
>> 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?
> 
> Again, that's much clearer than what is currently there. It might help
> if some of the language/definitions from pg_has_role() is used, though.
> 
> For example:
> A role X is a "MEMBER" of another role Y if there is a chain of GRANTs
> from X to Y via zero or more intermediate roles. This allows X to
> execute "SET ROLE Y".
> Additionally X has "USAGE" of Y if X and all the intermediate roles (but
> *not* necessarily Y) are marked INHERIT. In this case X automatically
> has the privileges of Y, without the need to "SET ROLE Y".
> 
> 
> Just my 2p, but being fairly new to postgres' roles and privilege set-up
> I can tell you that the things I have found difficult, but important, to
> get my head around are:
> 
> * A role either pulls in all privileges it can (INHERIT) or none at all
> (NOINHERIT). It is not possible to create a role that all direct members
> are guaranteed to require, or not require, a "SET ROLE" to use (i.e. you
> can't mark a role as "inheritable" or "not inheritable")
> 
> * A role's attributes are not inherited by its members - SUPERUSER,
> CREATEROLE, etc. The CREATE ROLE docs refer to these things as both
> "attributes" and "privileges", which is a bit unhelpful. It would be
> better to refer to them only as "attributes" everywhere, so it is clear
> that "attributes" are never inherited whereas "privileges" can be inherited.
> 
> * As mentioned above, "X is a member of Y" implies "X can SET ROLE Y".
> Membership requires a GRANT chain from X to Y.
> 
> * Also mentioned above, "X has usage of Y" implies "X doesn't need to
> SET ROLE Y, other than to use Y's attributes". Usage requires everything
> apart from Y in the GRANT chain to be marked INHERIT.


All good stuff. I will try to take this into account and submit an
actual proposed patch -- hopefully over this weekend.

> Is there the ability to include diagrams or other images in the postgres
> docs? I think it could really help. Boxes for roles, arrows for
> membership - pointing from group to member (to show the flow of
> privileges), with a solid line if the member has INHERIT and a broken
> line if they have NOINHERIT... that sort of thing.

We *just* very recently added the ability to add images. Not sure I want
to attempt creating one for this, but perhaps after I write the patch
you could give it a go with an image to match your thoughts?

By the way, I wrote an extension to aid in sorting this stuff out -- you
might want to have a look:

  https://github.com/CrunchyData/crunchy_check_access

Feedback welcomed. Patches even more so ;-)

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
signature.asc (application/pgp-signature, 833 B)