Re: New SET privilege for pg_has_role() in v16+

On 1/2/24 08:15, Dominique Devienne wrote:
> On Tue, Jan 2, 2024 at 5:09 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> On 1/2/24 07:24, Dominique Devienne wrote:
> > pg_has_role() from
> > https://www.postgresql.org/docs/current/functions-info.html
> <https://www.postgresql.org/docs/current/functions-info.html>
> > <https://www.postgresql.org/docs/current/functions-info.html
> <https://www.postgresql.org/docs/current/functions-info.html>>
> > added the 'SET' privilege in v16, and on top of the existing
> 'MEMBER'
> > and 'USAGE' ones:
>
> https://www.postgresql.org/docs/current/sql-set-role.html
> <https://www.postgresql.org/docs/current/sql-set-role.html>
>
> "[...], if the role was granted WITH SET TRUE [...]"
>
>
> That seems to be the important part of your RFTM answer, which is
> apparently new in v16.

There also seems to an override:

https://www.postgresql.org/docs/16/runtime-config-client.html#GUC-CREATEROLE-SELF-GRANT

"createrole_self_grant (string)

If a user who has CREATEROLE but not SUPERUSER creates a role, and
if this is set to a non-empty value, the newly-created role will be
granted to the creating user with the options specified. The value must
be set, inherit, or a comma-separated list of these. The default value
is an empty string, which disables the feature.

The purpose of this option is to allow a CREATEROLE user who is not
a superuser to automatically inherit, or automatically gain the ability
to SET ROLE to, any created users. Since a CREATEROLE user is always
implicitly granted ADMIN OPTION on created roles, that user could always
execute a GRANT statement that would achieve the same effect as this
setting. However, it can be convenient for usability reasons if the
grant happens automatically. A superuser automatically inherits the
privileges of every role and can always SET ROLE to any role, and this
setting can be used to produce a similar behavior for CREATEROLE users
for users which they create.
"

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com