Re: fixing CREATEROLE

From: walther(at)technowledgy(dot)de
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing CREATEROLE
Date: 2022-11-28 19:53:08
Message-ID: 5fb3262a-7ec4-f8ad-d0b7-4f31ac1bbfda@technowledgy.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-28 19:54:16 Re: Failed Assert in pgstat_assoc_relation
Previous Message David G. Johnston 2022-11-28 19:52:36 Re: fixing CREATEROLE