public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: [email protected]
To: [email protected]
Subject: Re: Misleading sentence about default privileges
Date: Mon, 21 Jun 2021 22:42:45 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

On Thu, Jun 17, 2021 at 09:07:11AM +0000, PG Doc comments form wrote:
> > You can change default privileges only for objects that will be created by
> yourself or by roles that you are a member of.
> 
> Yet, altering the default privileges `for role`'s that I am a member of
> (i.e. `target_role` in docs), does not affect privileges granted on objects
> created by other members of said role.
> 
> Seeing as separating Users (roles with log-in privilege) from Roles
> (containing concrete grants, unable to log in) seems a common, and
> recommendable pattern, I believe the statement is quite misleading.
> 
> For an example of expected behaviour, see this Stack Overflow question:
> https://stackoverflow.com/questions/56237907/why-doesnt-alter-default-privileges-work-as-expected
> 
> The only scenario I can think of where the statement makes sense seems quite
> foreign to me: 
> Scenario: I, say `role_a`, have log-in, and am also a member of another
> Role, say `role_b`, which also has login. Only objects created directly by
> `role_b` (i.e. not any of its members) are affected.
> 
> I suggest adding something like the following to the documentation:
> 
> " Note that only object created directly by _*target_role*_ , i.e. not any
> of its members, will have privileges granted. "

I researched this.  What it is saying is that you can modify the
defaults for your own role, or roles you are a member of.  The defaults
are applied based on the active role at the time you create an object. 
Here is an example run as the postgres user:

	CREATE ROLE demo NOLOGIN;
	
-->	ALTER DEFAULT PRIVILEGES FOR ROLE demo GRANT SELECT ON TABLES TO PUBLIC;
	
	CREATE TABLE test1 (x INTEGER);
	
-->	SET ROLE demo;
	
	CREATE TABLE test2 (x INTEGER);
	\dp test1
	                             Access privileges
	 Schema | Name  | Type  | Access privileges | Column privileges |
	Policies
	--------+-------+-------+-------------------+-------------------+----------
	
	 public | test1 | table |                   |                   |
	
	\dp test2
	                             Access privileges
	 Schema | Name  | Type  | Access privileges | Column privileges |
	Policies
	--------+-------+-------+-------------------+-------------------+----------
	
	 public | test2 | table | =r/demo          +|                   |
-->	        |       |       | demo=arwdDxt/demo |                   |

I am trying to think of wording that would make this documentation
section clearer, but I can't think of anything.	 Maybe the entire
concept of "active role at time of object creation" needs to be
explained more, since there is a lot of focus on owner without the idea
that this is really the active role.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Misleading sentence about default privileges
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox