Re: PG16.1 security breach? - Mailing list pgsql-general

From David G. Johnston
Subject Re: PG16.1 security breach?
Date
Msg-id CAKFQuwZ_ftX30SY4b7=hFW97gJUDnxkLYRw22LdpwDpvLMGgMg@mail.gmail.com
Whole thread Raw
In response to Re: PG16.1 security breach?  (Ron Johnson <ronljohnsonjr@gmail.com>)
List pgsql-general
On Wed, Jun 12, 2024 at 2:37 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Wed, Jun 12, 2024 at 4:36 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Mon, Jun 10, 2024 at 2:21 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> How is it that the default privilege granted to public doesn’t seem to care who the object creator
> is yet when revoking the grant one supposedly can only do so within the scope of a single role?

I don't understand what you wrote.  ALTER DEFAULT PRIVILEGES also only applies to objects
created by a single role when you grant default privileges.


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.  You can revoke other privs from public (can't you?), so why seemingly only do procedures/functions have this difficulty.


Neither domain, language, nor type seem problematic.  Which just leave connect and temp on databases which indeed have a similar issue but also the number of roles with createdb is likely significantly fewer than those with create on schema.

David J.

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: UPDATE with multiple WHERE conditions
Next
From: "David G. Johnston"
Date:
Subject: Re: UPDATE with multiple WHERE conditions