laurenz.albe@xxxxxxxxxxx wrote: > >> bryn@xxxxxxxxxxxx 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. https://www.postgresql.org/message-id/CA%2BTgmobGds7oefDjZUY%2Bk_J7p1sS%3DpTq3sZ060qdb%3DoKei1Dkw%40mail.gmail.com 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.)
