From: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Jeremy Smith <jeremy(at)musicsmith(dot)net>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: What happened to the tip "It is good practice to create a role that has the CREATEDB and CREATEROLE privileges..." |
Date: | 2023-04-20 16:17:49 |
Message-ID: | 68B5FB4F-C736-4202-8BEA-BBA5105FA947@yugabyte.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
laurenz(dot)albe(at)cybertec(dot)at wrote:
>
>> bryn(at)yugabyte(dot)com wrote:
>>
>> I do see that a role that has "createdb" and "createrole" is pretty powerful because, for example, a role with these attributes can use "set role" to become any other non-superuser (see the example below).
>
> A user with CREATEROLE can make herself a member of "pg_execute_server_program", which in turn allows a clever attacker on a normal installation to make herself superuser.
Yes, that's how the thread that Robert Haas started here begins.
It seems odd that this realization comes so late. And it seems odd to respond by removing the tip in question rather than by adding to it to explain that risk.
There's already a precedent for causing an error if a role with "createdb" attempts to grant itself a role with "super". A naïve observer like me would think that it would be possible to add other similar checks to cause an error in these other troublesome cases so that the now-removed tip could really have the value that whoever wrote it thought it already had.
(I'm assuming that the hackers must grant themselves special permission to change existing behavior to fix critical security bugs.)
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Millas | 2023-04-20 16:35:35 | missing something about json syntax |
Previous Message | shveta malik | 2023-04-20 12:39:21 | Re: Support logical replication of DDLs |