> On Jan 25, 2022, at 12:44 PM, Stephen Frost <sfrost@snowman.net> 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
forcedto 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
grantoption, tracked in an aclitem, and use that to determine if the user creating the role can give them away. But
that'sa bigger redesign of the system. Just touching how CREATEROLE works entails backwards compatibility problems.
I'dhate 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