[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: Make bloom extension trusted, but can not drop with normal user
From:       Masahiko Sawada <sawada.mshk () gmail ! com>
Date:       2021-09-30 8:14:51
Message-ID: CAD21AoBjfpo=zpeKOmsWk1MRMdt1FK8yuquAyej7eCUX1zqP1g () mail ! gmail ! com
[Download RAW message or body]

On Wed, Aug 25, 2021 at 12:38 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> 
> On Tue, Aug 24, 2021 at 8:17 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> > 
> > 
> > To me the issue is that the extension was modified to trusted by an end
> > user not the extension author. I gotta believe there is more to the
> > trusted then a flag in the control file. It would not be surprising to
> > me that an ad hoc modification would fail.
> > 
> 
> If the expected behavior here is that an ordinary user can drop a trusted extension \
> then I do not see how this error could present itself since, just like extension \
> creation, all the flag does is allow the user to become a superuser for purposes of \
> installing (or removing) the extension objects.  Per Tom, the pre-v14 drop behavior \
> is indeed a bug.  It is not going to be back-patched, nor has the documentation \
> been updated to say that DROP EXTENSION is effectively prevented due to the \
> existence of this bug (if you really need superuser to install the extension it \
> seems reasonable it requires the same to drop it). 

I'd missed this discussion and it seems not to be fixed yet in v13.

> Per an adjacent thread [1] this has apparently been fixed in v14 at [2] - but if so \
> (not tested it myself) then it seems like an unexpected side-effect since that \
> particular commit seems like a pure refactoring.

I have the same opinion on this. In v14 it seems to me that this has
been fixed by a side-effect of the commit b1d32d3. Looking at the
discussion of the commit, there is no discussion on this behavior
change.

While this behavior contradicts what the doc says ("This configuration
gives the calling user the right to drop the extension, but not to
modify individual objects within it) I also understand that it would
be better to avoid the risk of moving/removing superuser checks in
v13. So far the reported issues are only about making bloom trusted,
which seems not a common use case (right?). So probably we can come
back to this issue and discuss how to fix this issue in v13 when more
issues related to this bug are reported.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic