public inbox for [email protected]  
help / color / mirror / Atom feed
From: Mark Dilger <[email protected]>
To: Stephen Frost <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Bossart, Nathan <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Joshua Brindle <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Shinya Kato <[email protected]>
Subject: Re: CREATEROLE and role ownership hierarchies
Date: Tue, 25 Jan 2022 13:29:55 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>



> On Jan 25, 2022, at 12:44 PM, Stephen Frost <[email protected]> wrote:
> 
> As I mentioned in the patch review, having a particular bit set doesn't
> necessarily mean you should be able to pass it on- the existing object
> GRANT system distinguishes those two and it seems like we should too.
> In other words, I'm saying that we should be able to explicitly say just
> what privileges a CREATEROLE user is able to grant to some other role
> rather than basing it on what that user themselves has.

I like the way you are thinking, but I'm not sure I agree with the facts you are asserting.

I agree that "CREATE ROLE.. ROLE .." differs from "CREATE ROLE .. ADMIN ..", and "GRANT..WITH GRANT OPTION" differs from "GRANT..", but those only cover privileges tracked in an aclitem array.  The privileges CREATEDB, CREATEROLE, REPLICATION, and BYPASSRLS don't work that way.  There isn't a with/without grant option distinction for them.  So I'm forced to say that a role without those privileges must not give them away.

I'd be happier if we could get rid of all privileges of that kind, leaving only those that can be granted with/without grant option, tracked in an aclitem, and use that to determine if the user creating the role can give them away.  But that's a bigger redesign of the system.  Just touching how CREATEROLE works entails backwards compatibility problems.  I'd hate to try to change all these other things; we'd be breaking a lot more, and features that appear more commonly used.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company









view thread (2+ messages)

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], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: CREATEROLE and role ownership hierarchies
  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