Re: fixing CREATEROLE - Mailing list pgsql-hackers

From walther@technowledgy.de
Subject Re: fixing CREATEROLE
Date
Msg-id 5fb3262a-7ec4-f8ad-d0b7-4f31ac1bbfda@technowledgy.de
Whole thread Raw
In response to Re: fixing CREATEROLE  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas:
>> In my proposal, the "object" is not the GRANT of that role. It's the
>> role itself. So the default privileges express what should happen when
>> the role is created. The default privileges would NOT affect a regular
>> GRANT role TO role_spec command. They only run that command when a role
>> is created.
> 
> I agree that this is what you are proposing, but it is not what your
> proposed syntax says. Your proposed syntax simply says ALTER DEFAULT
> PRIVILEGES .. GRANT. Users who read that are going to think it
> controls the default behavior for all grants, because that's what the
> syntax says. If the proposed syntax mentioned CREATE ROLE someplace,
> maybe that would have some potential. A proposal to make a command
> that controls CREATE ROLE and only CREATE ROLE and mentions neither
> CREATE nor ROLE anywhere in the syntax is never going to be
> acceptable.

Yes, I agree - the abbreviated GRANT syntax is confusing/misleading in 
that case. Consistent with the other syntaxes, but easily confused 
nonetheless.

> It's no. Well, OK, you can do it, but it doesn't revoke anything,
> because you can only revoke your own grant, not the bootstrap
> superuser's grant.

Ah, I see. I didn't get that difference regarding the bootstrap 
superuser, so far.

So in that sense, the ADP GRANT would be an additional GRANT issued by 
the user that created the role in addition to the bootstrap superuser's 
grant. You can't revoke the bootstrap superuser's grant - but you can't 
modify it either. And there is no need to add SET or INHERIT to the 
boostrap superuser's grant, because you can grant the role yourself 
again, with those options.

I think it would be very strange to have a default for that bootstrap 
superuser's grant. Or rather: A different default than the minimum 
required - and that's just ADMIN, not SET, not INHERIT. When you have 
the minimum, you can always choose to grant SET and INHERIT later on 
yourself - and revoke it, too! But when the SET and INHERIT are on the 
boostrap superuser's grant - then there is no way for you to revoke SET 
or INHERIT on that grant anymore later.

Why should the superuser, who gave you CREATEROLE, insist on you having 
SET or INHERIT forever and disallow to revoke it from yourself?

Best,

Wolfgang



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: fixing CREATEROLE
Next
From: Tom Lane
Date:
Subject: Re: Failed Assert in pgstat_assoc_relation