Re: fixing CREATEROLE - Mailing list pgsql-hackers

From walther@technowledgy.de
Subject Re: fixing CREATEROLE
Date
Msg-id 9cd93d12-9f07-8afe-0174-c1c6809eae4e@technowledgy.de
Whole thread Raw
In response to Re: fixing CREATEROLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fixing CREATEROLE
Re: fixing CREATEROLE
List pgsql-hackers
Robert Haas:
>> 1) Automatically install an additional membership grant, with the CREATEROLE user as the grantor, specifying INHERIT
ORSET as TRUE (I personally favor attaching these to ALTER ROLE, modifiable only by oneself)
 
> 
> Hmm, that's an interesting alternative to what I actually implemented.
> Some people might like it better, because it puts the behavior fully
> under the control of the CREATEROLE user, which a number of you seem
> to favor.

+1

> I suppose if we did it that way, it could even be a GUC, like
> create_role_automatic_grant_options.

I don't think using GUCs for that is any better. ALTER DEFAULT 
PRIVILEGES is the correct way to do it. The only argument against it 
was, so far, that it's easy to confuse with default options for newly 
created role grants, due to the abbreviated grant syntax.

I propose a slightly different syntax instead:

ALTER DEFAULT PRIVILEGES GRANT CREATED ROLE TO role_specification WITH ...;

This, together with the proposal above regarding the grantor, should be 
consistent.

Is there any other argument to be made against ADP?

Note, that ADP allows much more than just creating a grant for the 
CREATEROLE user, which would be the case if the default GRANT was made 
TO the_create_role_user. But it could be made towards *other* users as 
well, so you could do something like this:

CREATE ROLE alice CREATEROLE;
CREATE ROLE bob;

ALTER DEFAULT PRIVILEGES FOR alice GRANT CREATED ROLE TO bob WITH SET 
TRUE, INHERIT FALSE;

This is much more flexible than role attributes or GUCs.

Best,

Wolfgang



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Decouple last important WAL record LSN from WAL insert locks
Next
From: Bharath Rupireddy
Date:
Subject: Re: Introduce a new view for checkpointer related stats