Re: PG16.1 security breach?

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: PG16.1 security breach?
Дата
Msg-id CAKFQuwZryjNtuNwiaYDmFpBjMQdvqGcZNp=m3gWKVBTXEPfa8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG16.1 security breach?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Wed, Jun 12, 2024 at 3:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ron Johnson <ronljohnsonjr@gmail.com> writes:
> On Wed, Jun 12, 2024 at 4:36 PM David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>> I think my point is that a paragraph like the following may be a useful
>> addition:
>>
>> If one wishes to remove the default privilege granted to public to execute
>> all newly created procedures it is necessary to revoke that privilege for
>> every superuser in the system

> That seems... excessive.

More to the point, it's wrong.  Superusers have every privilege there
is "ex officio"; we don't even bother to look at the catalog entries
when considering a privilege check for a superuser.  Revoking their
privileges will accomplish nothing, and it does nothing about the
actual source of the problem (the default grant to PUBLIC) either.

Apparently my forgetting the word "default" in front of privilege makes a big difference in understanding/meaning.

Alter Default Privileges FOR postgres Revoke Execute on Functions From PUBLIC;

That is what I meant, I was wrong in that I wrote permission instead of "d
If one wishes to remove the default privilege granted to public to execute
all newly created procedures it is necessary to revoke that [default] privilege for
every superuser in the system.

The FOR postgres part is inferred, it matches the current role if omitted.

If I now create (or even if there already existed) a new superuser named davidj and they create a function, the public pseudo-role will be able to execute that function.  You would first need to execute the above command, substituting davidj for postgres, if you want to prevent that.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Definging columns for INSERT statements
Следующее
От: Rich Shepard
Дата:
Сообщение: Re: Definging columns for INSERT statements