Re: Evidence of Ownership Issues During Restoration of Extension Member Objects

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: AKASH <akashbhujbal7051(at)gmail(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Evidence of Ownership Issues During Restoration of Extension Member Objects
Date: 2025-01-28 05:56:32
Message-ID: CAKFQuwYMWQRdhj0SPiW0KnmwMOi0pEmdyWKeyOxDa+GSb5U6VA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Monday, January 27, 2025, AKASH <akashbhujbal7051(at)gmail(dot)com> wrote:

> Addressing this limitation—either through improved documentation or
> tooling adjustments—would greatly benefit users managing complex permission
> models.
>

That most likely means taking Tom’s email of restrictions and adding them
to the documentation somewhere. We don’t really have a good way to modify
tooling to prohibit superusers from doing stuff like this that breaks their
system. But this should not be impacting production use cases if proper
testing of backup/restore is happening.

As an aside, none of the use cases are framed to directly motivate why you
would take the actions described, so we are still just left seeing
unnecessary attempts to make unsupported changes to the system permissions
setup and responding with “don’t do that”. An extension like pg_trgm has
little to no security implications necessitating complex permission setup,
AFAICS.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-01-28 06:33:50 Re: Evidence of Ownership Issues During Restoration of Extension Member Objects
Previous Message Christophe Pettus 2025-01-28 05:47:15 Re: Evidence of Ownership Issues During Restoration of Extension Member Objects