> adrian.klaver@aklaver.com wrote:
>
>> bryn@yugabyte.com wrote:
>>
>> Here's the examples that I mentioned. Please confirm that the changes brought by the commit referred to above won't
changehow it behaves in Version 15.2.
>
> The commit was over only documentation files
>
> doc/src/sgml/ref/alter_role.sgml
> doc/src/sgml/ref/create_role.sgml
> doc/src/sgml/ref/createuser.sgml
> doc/src/sgml/user-manag.sgml
>
> so I don't see how it can change behavior.
The account of the commit that Jeremy Smith referred to, here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1c77873727dfd2e48ab2ece84d1fb1676e95f9a5
had a reference to an email thread on the pgsql-hackers with subject "fixing CREATEROLE". It was started by Robert Haas
andit begins thus:
> https://www.postgresql.org/message-id/CA%2BTgmobGds7oefDjZUY%2Bk_J7p1sS%3DpTq3sZ060qdb%3DoKei1Dkw%40mail.gmail.com
>
> The CREATEROLE permission is in a very bad spot right now. The biggest problem that I know about is that it allows
youto trivially access the OS user account under which PostgreSQL is running, which is expected behavior for a
superuserbut simply wrong behavior for any other user. This is because CREATEROLE conveys powerful capabilities not
onlyto create roles but also to manipulate them in various ways, including granting any non-superuser role in the
systemto any new or existing user, including themselves.
The thread goes on forever. And it branches too. It's talking about possibly patching the code—precisely to bring about
achange in behavior. And I'm asking if the fix(es) under discussion would change the behavior of the code that I
showed.
The upshot of it all seems to be that the putative benefit of using a role the has only "createrole" and not "super" is
marginalbecause such a role can grant itself shipped dangerous roles like "pg_execute_server_program" and
"pg_write_server_files"
which are trivially exploitable.